| JDK 26 |
|---|
| 26Unresolved |
|
Blocks :
|
|
|
Blocks :
|
|
|
CSR :
|
|
|
Duplicate :
|
When ML-KEM and ML-DSA were introduced in JDK 24, the RFCs defining private key encodings for these algorithms had not been published yet. The drafts at the time, draft-ietf-lamps-kyber-certificates and draft-ietf-lamps-dilithium-certificates, described the private key only as “an opaque byte sequence,” without specifying a concrete format.
Based on that, the JDK 24 implementation adopted the encodings defined in NIST FIPS 203 and 204 — specifically, using the private key output from the ML-KEM.KeyGen function (Section 7.1 of FIPS 203), and the ML-DSA.KeyGen function (Section 5.1 of FIPS 204).
Now that RFC XXX (ML-KEM) and RFC 9881 (ML-DSA) have been published, their private key formats are formally defined as DER-encoded ASN.1 CHOICE types. For example, for ML-KEM-512:
ML-KEM-512-PrivateKey ::= CHOICE {
seed [0] OCTET STRING (SIZE (64)),
expandedKey OCTET STRING (SIZE (1632)),
both SEQUENCE {
seed OCTET STRING (SIZE (64)),
expandedKey OCTET STRING (SIZE (1632))
}
}
Similar structures are defined for ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, and ML-DSA-87.
The JDK 24 implementation currently uses the second option, `expandedKey OCTET STRING`. To comply with the final RFCs, we need to update our implementation to support the other two CHOICEs as well.
|