On Mon, 3 Feb 2025 15:57:30 GMT, Weijun Wang <wei...@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
