[WIP] kem: Kem trait for the whole algorithm type family
#2243
Conversation
Adds a `Kem` trait intended to be impl'd by ZSTs that describe the whole type family, including the decapsulation key, encapsulation key, and the sizes of the ciphertext and shared secret previously defined on the `KemParams` trait (which this subsumes). The remaining traits have been changed to be generic around `K: Kem` and now use it to source their constants or relevant types. `DecapsulationKey<K>` and `EncapsulationKey<K>` type aliases have been added, similar to the ones in `elliptic-curve`, which take care of doing `K as Kem` for you when accessing the associated types. The design of this trait largely matches the bespoke traits that people were defining different but similarly shaped-versions of in individual crates in https://github.com/RustCrypto/KEMs
| /// Often, this will just be a public key. However, it can also be a bundle of public keys, or it | ||
| /// can include a sender's private key for authenticated encapsulation. | ||
| pub trait Encapsulate: KemParams + TryKeyInit + KeyExport { | ||
| pub trait Encapsulate<K: Kem>: TryKeyInit + KeyExport { |
There was a problem hiding this comment.
Now that I think about it, these generic parameters are important for binding an impl of Encapsulate/(Try)Decapsulate to a specific KEM algorithm, e.g. if an HSM library wanted to add one.
Unlike signature we can't infer the algorithm from the return type.
There was a problem hiding this comment.
I'm also kind of torn using a generic here. There will probably be only one impl per type, so we don't need overlapping bounds.
It means that everyone needs to notate it in the downstream bounds, which is a little annoying, but they'll need to bound on Kem anyway since it's the trait holding everything together.
If we moved it to an associated type it would get out of the way, but then we should probably get rid of the Decapsulator trait so we don't have to worry about both Decapsulator and Decapsulate defining an associated Kem type.
We would, however, still have to worry about both Decapsulate and TryDecapsulate defining associated Kem types, and if we moved encapsulator to those traits they would then have overlapping encapsulator methods (which is the problem Decapsaulator exists to solve in the first place)
|
I'm going to try this out on https://github.com/RustCrypto/KEMs and if it looks good I'll mark the PR as ready for review |
| pub trait KemParams { | ||
| /// Size of the ciphertext (a.k.a. "encapsulated key") produced by [`Encapsulate::encapsulate`]. | ||
| /// This trait describes the entire type family used by a KEM. | ||
| pub trait Kem: Copy + Clone + Debug + Default + Eq + Ord + Send + Sync + 'static { |
There was a problem hiding this comment.
These are the same bounds as elliptic_curve::Curve. They're important when a type that impls Kem is used as a generic parameter on other types, so custom derive works because it doesn't freak out about the bounds of the ZST it's generic around.
Adds a
Kemtrait intended to be impl'd by ZSTs that describe the whole type family, including the decapsulation key, encapsulation key, and the sizes of the ciphertext and shared secret previously defined on theKemParamstrait (which this subsumes).The remaining traits have been changed to be generic around
K: Kemand now use it to source their constants or relevant types.DecapsulationKey<K>andEncapsulationKey<K>type aliases have been added, similar to the ones inelliptic-curve, which take care of doingK as Kemfor you when accessing the associated types.The design of this trait largely matches the bespoke traits that people were defining different but similarly shaped-versions of in individual crates in https://github.com/RustCrypto/KEMs
cc @rozbb