Encoding of ML-DSA private keys

[Sean Mullan]

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>