PQC: ML-KEM (Initial Public Draft)

[reneme]

Pull Request Dependencies

• Refactor: Kyber internals #3887

Descriptions

This builds on the existing Kyber implementation (and the flexibility added in #3387) to provide an implementation of ML-KEM as specified in the "initial public draft". Test vectors are taken from the reference implementation.

Note that each flavor of Kyber/ML-KEM can be disabled at compile time via the modules kyber, kyber_90s, ml_kem_ipd.

Caveats

It is somewhat unclear what the support guarantees should be for this. Perhaps we shouldn't even merge it into master but leave the Pull Request open until NIST publishes the final standard and never even release support for ML-KEM-ipd.

Note that it is an addition! Kyber-R3 (and 90s mode) continue to work as before.
Currently, I didn't expose ML-KEM-ipd in the FFI (or the python wrapper) and also didn't make it available in hybrid-TLS.

Example

#include <botan/pk_algs.h>
#include <botan/pubkey.h>
#include <botan/system_rng.h>

#include <cassert>
#include <iostream>

using namespace Botan;

int main() {
   // Alice
   System_RNG rng;
   auto sk = create_private_key("ML-KEM-ipd", rng, "ML-KEM-768-ipd");
   if(!sk) {
      std::cerr << "Failed to create private key\n";
      return 1;
   }
   auto pk = sk->public_key();

   // Bob
   const auto [ciphertext, shared_key_bob] = KEM_Encapsulation::destructure(PK_KEM_Encryptor(*pk, "Raw").encrypt(rng));

   // Alice
   auto shared_key_alice = PK_KEM_Decryptor(*sk, rng, "Raw").decrypt(ciphertext);

   // Test
   assert(shared_key_alice == shared_key_bob);
   std::cout << "Alice and Bob can now communicate securely!\n";
}

[coveralls]

coverage: 92.001% (-0.005%) from 92.006%
when pulling 2dcd938 on Rohde-Schwarz:feature/mlkem_ipd
into 13c7e5f on randombit:master.

[falko-strenzke]

@reneme, that's great news. I highly appreciate that the different versions can be controlled in the build and invoked at run-time independently.
As to whether the ipd version should be merged into the master branch: I clearly tend say it should, for the following reasons:

• Keeping it in a separate branch leaves the work of keeping the code up to date with the master branch either to a maintainer of the user of the branch.
• The "kyber" version is already in master and released. So the addition of ML-KEM-idp does not introduce really a new problem regarding the maintenance of pre-final ML-KEM versions.
• I think the decision whether and when to deprecate them and finally drop the pre-final versions of the PQC algorithms should best be taken after the final versions have been published. Considering the case of "Keccak", where the pre-final version is still contained in Botan – due to real world implementations still using it – it seems there might be a chance that the pre-final versions of the PQC algorithms also remain in the field. If that is not the case, they can be dropped after an adequate grace period.

[reneme]

Rebased after underlying #3887 had to get some conflicts resolved.