Skip to content

Conversation

@jmwample
Copy link
Contributor

Make is possible to wrap kem::(De|En)capsulationKey in external packages without exposing KemParams publicly.

Instead of making KemParams public and allowing external types to implement the interface, I have added a public trait Params which has KemParams as a public supertrait whose name is not publicly exported (private module). Rust API Guidelines

This makes it possible to do things like:

struct WrappedDecapsulationKey<P: Params> {
    key: DecapsulationKey<P>
}

This is more convenient than working with <P as KemCore>::DecapsulationKey.

Closes #65

@tarcieri
Copy link
Member

tarcieri commented Jan 21, 2026

In the latest prereleases of ml-kem you should be able to use DecapsulationKey and EncapsulationKey being generic over the Decapsulate and Encapsulate traits.

Do those do what you need in a generic context? Ideally I would like to get rid of a lot of the bespoke traits that various crates in this repo have which don't interoperate with each other.

@jmwample
Copy link
Contributor Author

I am going to close this PR and try your suggestion. The project has been on the back-burner for some time and when I circle back around I will likely rework around a number of other things.

Thank you for checking back in.

@jmwample jmwample closed this Jan 21, 2026
@tarcieri
Copy link
Member

I realized there may be one gap still: RustCrypto/traits#2213

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.

Downstream library usage of ml_kem::DecapsulationKey

2 participants