Assurance Level

[mkannwischer]

According to the PQCP charter, the goal for projects within PQCP is to
build high-assurance production-ready software implementations of forthcoming post-quantum cryptography standards, starting with the ML-KEM algorithm

During the first PQCP TSC meeting it was discussed that we should be more explicit on what we mean by high-assurance production-ready. This differs between different sub-projects of PQCP and it would be good to come up with some assurance levels to unify between different project.
For the next TSC meeting (May 23), each sub-project should document the corresponding interpretation of high-assurance production-ready and document the intended level of assurance.

Let's discuss here.

[mkannwischer]

Here is a draft of a definition of what I would aim for for a first release of mlkem-c-embedded

• Automated checking of positive and negative testvectors (NISTKAT + PQCP KAT)
• Automated static sanitizers
• Automated check for data-dependent timing instructions
• External code audit

All automated tests should be performed for all target architectures and ideally be performed both on the emulated and actual hardware platforms (if applicable).
For the code audits there is going to be a process to go through in the PQCA. There is some budget for this in the PQCA and we need to talk to the TAC to get this started.

Also see: https://github.com/pq-code-package/mlkem-c-aarch64/issues/37
Compared to the AArch64 repo, it's likely going to be harder to perform any kind of dynamic analysis as you can't run valgrind.

Any thoughts on this @rpls?