update MLKEM code points #511
Conversation
baentsch
commented
Sep 7, 2024
baentsch
commented
- Partially fixes Implement new ML-KEM hybrid key exchange in TLS #503.
- Updates code base with proper reference to MLKEM after Add ML-KEM / FIPS203 final liboqs#1899 landed without accompanying PR in oqsprovider.
Signed-off-by: Michael Baentsch <[email protected]>
|
@bhess -- didn't we agree in #351 that you'd look after this algorithm set wrt code points -- as this basically pertains to Kyber that IBM claims fame for? If my understanding is incorrect or this no longer holds (which I could understand as the press release is done and you may consider this "mission accomplished"), please let me know and I complete this PR beyond the standardized code points with further code points/OIDs of my choice as necessitated by the change of KATs in open-quantum-safe/liboqs#1899. Otherwise, please amend this PR in completion of open-quantum-safe/liboqs#1899. Thanks for letting me know. |
|
@baentsch: OIDs for the standards (ML-KEM, ML-DSA, SLH-DSA) are assigned by NIST, see https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration. TLS code points for x25519_mlkem768 and p256_mlkem768 are published here: https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-mlkem-01.html#name-iana-considerations. |
Signed-off-by: Michael Baentsch <[email protected]>
|
Thanks @bhess for the pointers. Without further activity on your side I thus assume you only keep supporting IBM Kyber and not NIST MLKEM. Your review of the PR would be welcome regardless. Now also asking Tresorit (@bencemali) and the IETF hackathon team (@johngray-dev as proxy) for their feedback as to whether (continued) use of their (e.g., BouncyCastle) OIDs is OK as well as Sandbox regarding code points (@thb-sb as proxy). |
|
@baentsch, it's ok |
Signed-off-by: Michael Baentsch <[email protected]>
There was a problem hiding this comment.
Thanks for the update @baentsch. I'll do an accompanying -tracker branch for the upcoming ML-DSA liboqs integration.
We currently don't plan to assign additional OIDs besides the standardized ones.
Is the "share reversal" for x25519_mlkem768 planned as a separate PR?
I certainly don't plan to include it in this PR. This is only meant to bring CI back to green. |
* update X25519-MLKEM768 code point Signed-off-by: Michael Baentsch <[email protected]> * further MLKEM (O)ID updates Signed-off-by: Michael Baentsch <[email protected]> * set p256_mlkem768 code point as per standard Signed-off-by: Michael Baentsch <[email protected]> --------- Signed-off-by: Michael Baentsch <[email protected]> Signed-off-by: Norman Ashley <[email protected]>
