ML-KEM keys seed storage

[DarkaMaul]

Problem:

AWS-LC can decode ML-KEM private keys from the compact 64-byte seed format but cannot encode to that format. After key generation the seed is discarded and kem_priv_encode always emits the expanded secret key.

In the encoding part, a comment acknowledges this:

aws-lc/crypto/evp_extra/p_kem_asn1.c

Line 238 in 863ed59

!CBB_add_asn1(&private_key, &expanded_key, CBS_ASN1_OCTETSTRING) || // expandedKey CHOICE variant, AWS-LC uses expandedKey for the moment

Compare the two structs (MLDSA and MLKEM):

aws-lc/crypto/fipsmodule/pqdsa/internal.h

Lines 70 to 76 in 863ed59

	// PQDSA_KEY structure and helper functions.
	struct pqdsa_key_st {
	const PQDSA *pqdsa;
	uint8_t *public_key;
	uint8_t *private_key;
	uint8_t *seed;
	};

aws-lc/crypto/fipsmodule/kem/internal.h

Lines 62 to 66 in 863ed59

	struct kem_key_st {
	const KEM *kem;
	uint8_t *public_key;
	uint8_t *secret_key;
	};

Solution:

1. Add uint8_t *seed to kem_key_st, mirroring pqdsa_key_st:

   struct kem_key_st {
       const KEM *kem;
       uint8_t *public_key;
       uint8_t *secret_key;
       uint8_t *seed;
   };

2. Populate the seed during keygen, the same way ML-DSA does in pkey_pqdsa_keygen.

3. Update kem_priv_encode to serialize the seed, mirroring pqdsa_priv_encode which emits seed [0] OCTET STRING when the seed is available.

• Does this change any public APIs? No
• Which algorithm(s) will this impact? ML-KEM-512, ML-KEM-768, ML-KEM-1024.

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: FIPS 203
• Related Issues: None
• Will the Usage Guide or other documentation need to be updated? I'm unsure
• Testing: Unit tests in the KEM test suite covering the cases listed above for all three ML-KEM variants.
  • Will this change trigger AWS LibCrypto Formal Verification changes? No
  • Should this change be fuzz tested? No

Out of scope:

Is there anything the solution will intentionally NOT address?

[dconnolly]

If you keep the seed and the expanded format secret_key around together, you have to implement checks that they continue to agree with each other

[reaperhulk]

Just to add a bit of context here: this is a feature we need to expose PQ using AWS-LC as a backend in pyca/cryptography. We do not intend to expose support for parsing or serialization of expanded forms; for safety reasons we strongly prefer seed only construction.

[dkostic]

hi all, thanks for your interest in this topic. we are working on it, expect a patch soon.

[geedo0]

If you keep the seed and the expanded format secret_key around together, you have to implement checks that they continue to agree with each other

Unless anyone feels strongly about it, we will be prefer the seed encoding whenever it's available and fallback to expanded form only in cases where that's all we have. There will never be a case where we output the both form. If that turns out to be necessary in the future, we can always revisit.