ML-KEM private keys not compatible with draft-ietf-lamps-kyber-certificates-06 (seed as private key)

[tomato42]

Describe the bug The private key files generated using oqsprovider do not follow the ~draft-ietf-lamps-cms-kyber-07~ draft-ietf-lamps-kyber-certificates-06 standard. More specifically, the saved private key is not the seed used to generate it but the expanded value.

To Reproduce Steps to reproduce the behaviour:

1. openssl genpkey -out private-key.pem -algorithm mlkem512
2. inspect private-key.pem

Expected behavior The file should be small, just two lines of base64 encoded data. Instead the file is over 4kiB large.

Environment (please complete the following information):

• OS: RHEL-10
• OpenSSL version: openssl-3.2.2-14.el10
• oqsprovider version: oqsprovider-0.8.0-2.el10.

Please run the following commands to obtain the version information:

• For OpenSSL: openssl version :

  OpenSSL 3.2.2 4 Jun 2024 (Library: OpenSSL 3.2.2 4 Jun 2024)
  

• For oqsprovider: openssl list -providers:

  Providers:
    default
      name: OpenSSL Default Provider
      version: 3.2.2
      status: active
    oqsprovider
      name: OpenSSL OQS Provider
      version: 0.8.0
      status: active
  

[baentsch]

I'm afraid this is not a bug but a deliberate decision for encoding strictly pursuant the NIST guidance to not use seeds outside of testing. Also, as oqsprovider is completely algorithm-agnostic, this is a key representation issue that has to be changed in liboqs and possibly, its upstream(s). Created https://github.com/open-quantum-safe/liboqs/issues/2032 to track.

[SWilson4]

Reading the draft, I'm only seeing one place that specifies a short private key: the example in Appendix C.2. This was changed less than a month ago; previously the example had used the "expanded" format.

Meanwhile, Section 1.2 explicitly states that the Decapsulate function is ML-KEM.Decaps() from FIPS 203. This function operates on an expanded key, not a seed. RFC 9629 lists only three KEM functions: Keygen, Encaps, and Decaps. Is there any guidance in the CMS draft, apart from the example, regarding what processing—outside the three-function KEM interface—must be done to use the decapsulation function with a short key?

[tomato42]

@SWilson4 the IETF LAMPS consensus is that private keys of all three of the NIST algorithms should be stored as seeds, not as expanded keys, for the private key exchange file formats (PKCS#8, PKCS#12). How the specific cryptographic module handles the private key internally is outside the scope of any standards.

And yes, that means that for RFC 9629 sk should be a 64 byte long octet string, for all three ML-KEM parameter sets.

Also, sorry, should have referenced draft-ietf-lamps-kyber-certificates-06 instead, not the CMS draft.

[SWilson4]

@SWilson4 the IETF LAMPS consensus is that private keys of all three of the NIST algorithms should be stored as seeds, not as expanded keys, for the private key exchange file formats (PKCS#8, PKCS#12). How the specific cryptographic module handles the private key internally is outside the scope of any standards.

And yes, that means that for RFC 9629 sk should be a 64 byte long octet string, for all three ML-KEM parameter sets.

Also, sorry, should have referenced draft-ietf-lamps-kyber-certificates-06 instead, not the CMS draft.

OK, that makes sense, Thanks!