Skip to content

module-lattice crate#199

Merged
tarcieri merged 1 commit intomasterfrom
module-lattice
Jan 27, 2026
Merged

module-lattice crate#199
tarcieri merged 1 commit intomasterfrom
module-lattice

Conversation

@tarcieri
Copy link
Copy Markdown
Member

Initial prerequisite for #112.

Adds a module-lattice crate intended for sharing functionality between ml-kem and ml-dsa. The crate is an extraction of the ml-dsa crate's module_lattice module (already designed for this purpose), and has been extracted as of this commit:

RustCrypto/signatures@942de7f

Several types/methods were made pub in order to be usable in this capacity.

This commit doesn't actually try to use module-lattice in conjunction with ml-kem, rather it just extracts the functionality from ml-dsa. However, having this crate in-repo with ml-kem should help simplify wiring it up.

A code comment in lib.rs notes there are currently almost no tests(!) which seems problematic, although it tends to be our typical problem with crates like this where they're designed to be abstract and you need something concrete to test against.

It suggests moving the actual field definitions to that crate and testing against those, which seems like a reasonable next step.

Perhaps we can find a way to integration test PRs against ml-dsa as well (or at least ensure it still builds), using a special testing project with patch.crates-io directives.

@tarcieri tarcieri requested a review from bifurcation January 27, 2026 23:05
Initial prerequisite for #112.

Adds a `module-lattice` crate intended for sharing functionality between
`ml-kem` and `ml-dsa`. The crate is an extraction of the `ml-dsa`
crate's `module_lattice` module (already designed for this purpose),
and has been extracted as of this commit:

RustCrypto/signatures@942de7f

Several types/methods were made `pub` in order to be usable in this
capacity.

This commit doesn't actually try to use `module-lattice` in conjunction
with `ml-kem`, rather it just extracts the functionality from `ml-dsa`.
However, having this crate in-repo with `ml-kem` should help simplify
wiring it up.

A code comment in `lib.rs` notes there are currently almost no tests(!)
which seems problematic, although it tends to be our typical problem
with crates like this where they're designed to be abstract and you need
something concrete to test against.

It suggests moving the actual field definitions to that crate and
testing against those, which seems like a reasonable next step.

Perhaps we can find a way to integration test PRs against `ml-dsa` as
well (or at least ensure it still builds), using a special testing
project with `patch.crates-io` directives.
@tarcieri tarcieri merged commit a2a44ea into master Jan 27, 2026
44 checks passed
@tarcieri tarcieri deleted the module-lattice branch January 27, 2026 23:10
tarcieri added a commit to RustCrypto/signatures that referenced this pull request Jan 27, 2026
We can share code between `ml-kem` and `ml-dsa`, and the previous
`ml_dsa::module_lattice` submodule was designed so it could be extracted
and shared with `ml-kem`.

That just happened in RustCrypto/KEMs#199, which pulled the
`module_lattice` module out of this crate at 942de7f and extracted it
into its own crate, which is now published as `module-lattice`
v0.1.0-pre.0.

This removes the previous `module_lattice` module and switches to the
new crate.

See also: RustCrypto/KEMs#112
tarcieri added a commit to RustCrypto/signatures that referenced this pull request Jan 27, 2026
We can share code between `ml-kem` and `ml-dsa`, and the previous
`ml_dsa::module_lattice` submodule was designed so it could be extracted
and shared with `ml-kem`.

That just happened in RustCrypto/KEMs#199, which pulled the
`module_lattice` module out of this crate at 942de7f and extracted it
into its own crate, which is now published as `module-lattice`
v0.1.0-pre.0.

This removes the previous `module_lattice` module and switches to the
new crate.

See also: RustCrypto/KEMs#112
@tarcieri tarcieri mentioned this pull request Apr 28, 2026
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)
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.

1 participant