Skip to content

ml-kem: define FieldElement using module_lattice::algebra::Elem#204

Merged
tarcieri merged 1 commit intomasterfrom
ml-kem/use-module-lattice-field-element-type
Jan 28, 2026
Merged

ml-kem: define FieldElement using module_lattice::algebra::Elem#204
tarcieri merged 1 commit intomasterfrom
ml-kem/use-module-lattice-field-element-type

Conversation

@tarcieri
Copy link
Copy Markdown
Member

Replaces the FieldElement defined in the ml-kem crate using one defined with the Elem type from the module-lattice crate, namely as a type alias thereof.

This is the first step towards actually using the generic implementation shared with the ml-dsa crate.

This necessitated adding a subtle feature to module-lattice so we can define ConstantTimeEq on Elem.

Uses the module_lattice::define_field! macro to define a new BaseField type for ml-kem, using the modulus 3329, which replaces several inherent constants previously defined on Field.

The previous FieldElement::base_case_multiply method was turned into a private free function within algebra, since we can't define an inherent method on an external type.

@tarcieri tarcieri requested a review from bifurcation January 28, 2026 23:32
Replaces the `FieldElement` defined in the `ml-kem` crate using one
defined with the `Elem` type from the `module-lattice` crate, namely as
a type alias thereof.

This is the first step towards actually using the generic implementation
shared with the `ml-dsa` crate.

This necessitated adding a `subtle` feature to `module-lattice` so we
can define `ConstantTimeEq` on `Elem`.

Uses the `module_lattice::define_field!` macro to define a new
`BaseField` type for `ml-kem`, using the modulus 3329, which replaces
several inherent constants previously defined on `Field`.

The previous `FieldElement::base_case_multiply` method was turned into a
private free function within `algebra`, since we can't define an
inherent method on an external type.
@tarcieri tarcieri force-pushed the ml-kem/use-module-lattice-field-element-type branch from 303875a to 643f825 Compare January 28, 2026 23:35
@tarcieri tarcieri merged commit 94d8634 into master Jan 28, 2026
44 checks passed
@tarcieri tarcieri deleted the ml-kem/use-module-lattice-field-element-type branch January 28, 2026 23:41
@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