RFR: 8347938: Switch to latest ML-KEM private key encoding [v6]

Weijun Wang weijun at openjdk.org
Mon Feb 3 16:04:52 UTC 2025


On Mon, 3 Feb 2025 15:57:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IERTF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-06 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-07. Most importantly, the seed used to generate a key pair is now stored in the private key.
>> 
>> Both the seed and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key that contains the seed, both fields will be filled. If the PKCS #8 encoding only contains the expanded key (which does not conform to the current drafts but might have been created earlier), the expanded key will be read and used in KEM and signature operations.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change name from "alt" to "transformed"; supporting jdk24 encoding

A new commit has been pushed. The most significant change is renaming `alt` to `transformed`, along with extensive comment updates and some minor behavior modifications:  

1. Added support for JDK 24 private key encodings, i.e. transformed format wrapped in an OCTET STRING.  
2. Fixed a bug in `NamedPKCS8Key::getTransformed`, which no longer compares lengths.  
3. Fixed a bug in `ML_DSA_Impls::seedToTransformed`, ensuring `sk` is cleaned up in a `finally` block.  
4. `NamedKeyFactory::implTransform` now has a default implementation, assuming encoding and computations use the same format. While this is not the case for ML-KEM and ML-DSA, it serves as a reasonable default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23376#issuecomment-2631418553


More information about the security-dev mailing list