<div dir="ltr">Hi,<div><br></div><div>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.</div><div>However, the industry is aligning behind the seed-form. [1]</div><div>For instance, BoringSSL removed[2] support for parsing expanded-form private keys, and plans on adding support for reading seed-form private keys instead.</div><div><br></div><div>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.</div><div><br></div><div>It'd be much preferred if the `PrivateKey.getEncoded` produced the seed-form encoding directly.</div><div>It looks like the JDK is already perfectly happy to use private keys that do that, at least in the testing I did.</div><div><br></div><div>Thanks,</div><div>Chris</div><div><br></div><div>[1]: <a href="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</a></div><div>[2]: <a href="https://boringssl.googlesource.com/boringssl/+/92a7368bad899b3c81fb99feff33515ee7eb8bb5">https://boringssl.googlesource.com/boringssl/+/92a7368bad899b3c81fb99feff33515ee7eb8bb5</a></div></div>