-
Bug
-
Resolution: Unresolved
-
P2
-
25
-
None
In the implementation of [JEP-496](https://openjdk.org/jeps/496), the PKCS #8 encoding of an ML-KEM private key includes the complete private key material as defined in FIPS 203: `dk_PKE ‖ ek ‖ H(ek) ‖ z`. We also noted that "The encoding used by the ML-KEM KeyFactory is defined in [a draft IETF RFC](https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/). We will track changes in this draft until it is published."
In November 2024, the 5th version of this draft clarified that "an ML-KEM private key is encoded by storing its 64-octet seed in the privateKey field", which is different from our current encoding format.
Later on, there have been more proposals on the encoding. See the mails at https://mailarchive.ietf.org/arch/msg/spasm/6iUmCadOg3PfGja7j26-MUXTUVk/ and https://mailarchive.ietf.org/arch/msg/spasm/50v8oLi5XObC7AIL4DH337_Anos/.
In November 2024, the 5th version of this draft clarified that "an ML-KEM private key is encoded by storing its 64-octet seed in the privateKey field", which is different from our current encoding format.
Later on, there have been more proposals on the encoding. See the mails at https://mailarchive.ietf.org/arch/msg/spasm/6iUmCadOg3PfGja7j26-MUXTUVk/ and https://mailarchive.ietf.org/arch/msg/spasm/50v8oLi5XObC7AIL4DH337_Anos/.
- csr for
-
JDK-8349163 Switch to latest ML-KEM private key encoding
-
- Draft
-
- is blocked by
-
JDK-8339009 JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
-
- Closed
-
- links to
-
Review(master) openjdk/jdk/23376