Hi Chris,
Yes we are aware of the issue and there are two open issues tracking
this, one for ML-KEM and one for ML-DSA:
https://bugs.openjdk.org/browse/JDK-8347938
https://bugs.openjdk.org/browse/JDK-8347941
Stay tuned for further progress on resolving these issues.
--Sean
On 1/30/25 12:59 PM, Chris Vest wrote:
Hi,
I downloaded JDK 24 EA to play with the new ML-DSA features, and noticed
that the `PrivateKey.getEncoded()` produces the expanded-form private
key format.
However, the industry is aligning behind the seed-form. [1]
For instance, BoringSSL removed[2] support for parsing expanded-form
private keys, and plans on adding support for reading seed-form private
keys instead.
The JDK 24 EA throws away the seed after generating the private keys, so
in order to produce seed-form PEMs, I find myself wrapping the
`SecureRandom` to capture it, and then wrapping the `PrivateKey` to
override the `getEncoded`, both of which are uncomfortable looking hacks.
It'd be much preferred if the `PrivateKey.getEncoded` produced the seed-
form encoding directly.
It looks like the JDK is already perfectly happy to use private keys
that do that, at least in the testing I did.
Thanks,
Chris
[1]: https://www.ietf.org/archive/id/draft-ietf-lamps-dilithium-
certificates-06.html#name-private-key-format <https://www.ietf.org/
archive/id/draft-ietf-lamps-dilithium-certificates-06.html#name-private-
key-format>
[2]: https://boringssl.googlesource.com/boringssl/
+/92a7368bad899b3c81fb99feff33515ee7eb8bb5 <https://
boringssl.googlesource.com/boringssl/
+/92a7368bad899b3c81fb99feff33515ee7eb8bb5>
