Summary

Change the ML-KEM private key encoding to match section 5 of https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-07#name-private-key-format — "an ML-KEM private key is encoded by storing its 64-octet seed in the privateKey field".

Problem

When ML-KEM was originally developed in OpenJDK, earlier revisions of draft-ietf-lamps-kyber-certificates stated only that "the private key is always an opaque byte sequence" without specifying its exact format. Therefore, we assumed it to be the same as the private key defined in NIST FIPS 203 — specifically, the private key part of the return value from the ML-KEM.KeyGen function, as defined in Section 7.1 of FIPS 203.

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

In short, an ML-KEM private key is encoded by storing its 64-octet seed in the privateKey field as follows.

[FIPS203] specifies two formats for an ML-KEM private key: a 64-octet seed and an (expanded) private key, which is referred to as the decapsulation key. The expanded private key (and public key) is computed from the seed using ML-KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as d and the remaining 32 octets as z.

We are using the "expanded" format now.

The latest revision is 7 with the same requirement.

Solution

Update our implementation to encode the 64-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.