Skip to content

Conversation

@tarcieri
Copy link
Member

First, this commit completely migrates EncapsulationKey to using only the kem/crypto-common traits: KeySizeUser, TryKeyInit, KeyExport, and changes any remaining uses to use only the new traits.

Since DecapsulationKey uses those same traits for handling Seeds, the only remaining use of the old EncodedSizeUser trait is handling the expanded form of DecapsulationKey. So this commit repurposes it into an ExpandedKeyEncoding trait.

Like DecapsulationKey::from_expanded, the trait has been marked deprecated with a rationale given in the documentation for ExpandedKeyEncoding, namely that the expanded form has only disadvantages when compared to seeds which are significantly smaller, uniformly sized, and avoid the need to do expanded key validation. It also notes several ML-KEM libraries have dropped support entirely.

In the ml-kem crate, for now, we still need this functionality if only for tests which have been written generically, including but not limited to the ones that run the NIST ACVP vectors.

@tarcieri tarcieri force-pushed the ml-kem/expanded-key-encoding-trait branch 3 times, most recently from d42c980 to f2eeec2 Compare January 31, 2026 01:46
First, this commit completely migrates `EncapsulationKey` to using only
the `kem`/`crypto-common` traits: `KeySizeUser`, `TryKeyInit`,
`KeyExport`, and changes any remaining uses to use only the new traits.

Since `DecapsulationKey` uses those same traits for handling `Seed`s,
the only remaining use of the old `EncodedSizeUser` trait is handling
the expanded form of `DecapsulationKey`. So this commit repurposes it
into an `ExpandedKeyEncoding` trait.

Like `DecapsulationKey::from_expanded`, the trait has been marked
deprecated with a rationale given in the documentation for
`ExpandedKeyEncoding`, namely that the expanded form has only
disadvantages when compared to seeds which are significantly smaller,
uniformly sized, and avoid the need to do expanded key validation.
It also notes several ML-KEM libraries have dropped support entirely.

In the `ml-kem` crate, for now, we still need this functionality if only
for tests which have been written generically, including but not limited
to the ones that run the NIST ACVP vectors.
@tarcieri tarcieri force-pushed the ml-kem/expanded-key-encoding-trait branch from f2eeec2 to 07802fb Compare January 31, 2026 01:48
@tarcieri tarcieri merged commit 38c5385 into master Jan 31, 2026
23 checks passed
@tarcieri tarcieri deleted the ml-kem/expanded-key-encoding-trait branch January 31, 2026 01:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants