ml-kem: add DecapsulationKey::from_expanded#163
Merged
Conversation
This is intended to subsume the uses of the `EncodedSizeUser` trait, providing a way for users who insist on using the expanded key format to be able to initialize `DecapsulationKey`s. To deter its use, it's marked as deprecated. Many implementations have opted not to support it at all, and in the future we can potentially consider removing it (which would allow `to_seed` to be infallible). After this, it should be possible to deprecate `EncodedSizeUser` as well, and remove it in a future release.
tarcieri
force-pushed
the
ml-kem/decapsulation-key-from-expanded
branch
from
51e70a4 to
c6f9150
Compare
tarcieri
added a commit
to RustCrypto/signatures
that referenced
this pull request
Jan 10, 2026
Renames `EncodedSigningKey` to `ExpandedSigningKey` to contrast it with seeds, the preferred API. Also renames the `decode` and `encode` functions to `from_expanded` and `to_expanded`, similar to the changes made to `ml-kem`'s `DecapsulationKey` in RustCrypto/KEMs#163, which also deprecated these APIs. We don't properly implement validation of such keys which can lead to panics in the event they were improperly or maliciously generated (#1133), a problem avoided by using seeds. For now, this merely documents the panic condition. Most implementers have opted not to provide support for this key format due to these problems (it's also actually more expensive to validate an expanded key than it is to use a seed), and also where seeds are the same size regardless of security level, the expanded keys vary in size.
tarcieri
added a commit
to RustCrypto/signatures
that referenced
this pull request
Jan 10, 2026
Renames `EncodedSigningKey` to `ExpandedSigningKey` to contrast it with seeds, the preferred API. Also renames the `decode` and `encode` functions to `from_expanded` and `to_expanded`, similar to the changes made to `ml-kem`'s `DecapsulationKey` in RustCrypto/KEMs#163, which also deprecated these APIs. We don't properly implement validation of such keys which can lead to panics in the event they were improperly or maliciously generated (#1133), a problem avoided by using seeds. For now, this merely documents the panic condition. Most implementers have opted not to provide support for this key format due to these problems (it's also actually more expensive to validate an expanded key than it is to use a seed), and also where seeds are the same size regardless of security level, the expanded keys vary in size.
tarcieri
added a commit
to RustCrypto/signatures
that referenced
this pull request
Jan 10, 2026
Renames `EncodedSigningKey` to `ExpandedSigningKey` to contrast it with seeds, the preferred API. Also renames the `decode` and `encode` functions to `from_expanded` and `to_expanded`, similar to the changes made to `ml-kem`'s `DecapsulationKey` in RustCrypto/KEMs#163, which also deprecated these APIs. We don't properly implement validation of such keys which can lead to panics in the event they were improperly or maliciously generated (#1133), a problem avoided by using seeds. For now, this merely documents the panic condition. Most implementers have opted not to provide support for this key format due to these problems (it's also actually more expensive to validate an expanded key than it is to use a seed), and also where seeds are the same size regardless of security level, the expanded keys vary in size.
Merged
tarcieri
added a commit
that referenced
this pull request
Apr 28, 2026
## Added - `Seed` support e.g. `DecapsulationKey::from_seed` (#133, #138) - PKCS#8 support (#135) - `KeyInit`, `KeySizeUser`, and `KeyExport` impls for decapsulation keys (#156, #228) - Parameter set modules: `ml_kem_512`, `mk_kem_768`, `mk_kem_1024` (#162) - `DecapsulationKey::from_expanded` deprecated compatibility support (#163) - `TryKeyInit` and `KeyExport` impls for encapsulation keys (#188) - Validations against Wycheproof test vectors (#213, #214, #215, #217) - Implement `kem::Kem` trait (#223) - Support for `kem::FromSeed` trait (#255) ## Changed - Edition changed to 2024 and MSRV bumped to 1.85 (#118) - Relax MSRV policy and allow MSRV bumps in patch releases - Upgrade `hybrid-array` dependency to 0.4 (#129) - Extract `module-lattice` crate (#199, #202, #204, #209, #210, #211, #212, #218, #219, #220) - Replace `EncodedSizeUser` with `ExpandedKeyEncoding` (#226) - Bump `getrandom` to v0.4 (#245) - Bump `rand_core` to v0.10 (#245) - Migrate from `subtle` to `ctutils` (#277) - Bump `sha3` dependency to v0.11 (#282) - Bump `kem` dependency to v0.3 (#283) - Bump `pkcs8` dependency to v0.11 (#291) ## Fixed - Validate encryption/encapsulation keys (#179) - Validate expanded decapsulation key hash (#207) ## Removed - `Kem` struct and `KemCore` trait - replaced by `kem::Kem` (#223)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is intended to subsume the uses of the
EncodedSizeUsertrait, providing a way for users who insist on using the expanded key format to be able to initializeDecapsulationKeys.To deter its use, it's marked as deprecated. Many implementations have opted not to support it at all, and in the future we can potentially consider removing it (which would allow
to_seedto be infallible).After this, it should be possible to deprecate
EncodedSizeUseras well, and remove it in a future release.