Summary

Change the ML-DSA private key encoding to match section 6 of https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-06#name-private-key-format — "An ML-DSA private key is encoded by storing its 32-octet seed in the privateKey field".

Problem

When ML-DSA was originally developed in OpenJDK, earlier revisions of draft-ietf-lamps-dilithium-certificates stated that "A fully populated ML-DSA private key consists of 6 parameters. The size necessary to hold all private key elements is 32+32+32+32*[(k+l)*ceiling(log(2*eta+1))+13*k] bytes", this matches the private key defined in NIST FIPS 204 — specifically, the private key part of the return value from the ML-DSA.KeyGen function, as defined in Section 5.1 of FIPS 204.

However, in November 2024, the revision 5 of the IETF draft added these lines:

An ML-DSA private key is encoded by storing its 32-octet seed in the privateKey field as follows.

[FIPS204] specifies two formats for an ML-DSA private key: a 32-octet seed (xi) and an (expanded) private key. The expanded private key (and public key) is computed from the seed using ML-DSA.KeyGen_internal(xi) (algorithm 6).

We are using the "expanded" format now.

The latest revision is 6 with the same requirement.

Solution

Update our implementation to encode the 32-octet seed as the private key in order to keep up with the latest IETF draft and interoperate with PQC implementation by other vendors.

Specification

No specification change.