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

Weijun Wang weijun at openjdk.org
Thu May 1 11:57:45 UTC 2025


On Wed, 30 Apr 2025 22:33:24 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> The private key encoding formats of ML-KEM and ML-DSA are updated to match the latest IETF drafts at: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08 and https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10. New security/system properties are introduced to determine which CHOICE a private key is encoded.
>> 
>> Both the encoding and the expanded format are stored inside a `NamedPKCS8Key` now. When loading from a PKCS #8 key, the expanded format is either calculated or copied from the input.
>
> src/java.base/share/classes/sun/security/util/KeyUtil.java line 506:
> 
>> 504:                 if (seed == null) return null;
>> 505:                 skOctets = new byte[seed.length + 2];
>> 506:                 skOctets[0] = (byte)0x80;
> 
> Is there any value in using the DerValue class to put a name on these constants? I think what you have is easy enough to read.

You mean I can use `DerValue.TAG_CONTEXT + 0` instead of 0x80? I can, but yes it's no more readable than the number itself. It's probably all about consistency. If I use `TAG_CONTEXT` here, I might also need to use `tag_OctetString`, `tag_Sequence`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24969#discussion_r2070188958


More information about the security-dev mailing list