[WIP] kdf crate
#1879
[WIP] kdf crate
#1879
Conversation
Traits which provide an API for interacting with Key Derivation Functions. We have several of these located at https://github.com/rustcrypto/kdfs and password-based KDFs at https://github.com/RustCrypto/password-hashes but the APIs for using these are typically just free functions, whereas traits could provide a common API.
|
I opened this up for discussion primarily, and also reserved the I think we probably need a lot more traits than this, particularly ones for representing the "expand" and "extract" steps in proper KDFs like HKDF. |
| #![warn(missing_docs, unused_qualifications, missing_debug_implementations)] | ||
|
|
||
| /// Use the KDF to derive the given amount of output. | ||
| pub trait Derive { |
There was a problem hiding this comment.
Perhaps this should be Expand?
| pub trait Derive { | |
| pub trait Expand { |
There was a problem hiding this comment.
I guess one question is: does the "expand" name make sense for one-shot KDFs which don't provide separate "extract" and "expand" steps?
There was a problem hiding this comment.
Maybe it's better to call it KeyDeriveFn and name the method derive_key? Though the Fn part is a bit problematic since it may be confused with the Fn closure traits.
| pub trait Derive { | ||
| /// Consumes the KDF instance and derives as much data as will fit in `out`, | ||
| /// overwriting its contents. | ||
| fn derive(self, out: &mut [u8]); |
There was a problem hiding this comment.
I made this consume self, but it could potentially borrow self mutably, which would allow for calling it multiple times:
| fn derive(self, out: &mut [u8]); | |
| fn derive(&mut self, out: &mut [u8]); |
There was a problem hiding this comment.
It also may be worth to provide derivation parameters. For example, in the hkdf case it would be okm. And the method should probably return Result. It would b needed for both concat-kdf and bake-kdf.
There was a problem hiding this comment.
Yeah, this trait assumes a separate init step which could have its own params, but also notably expand has an "info" parameter, at least in HKDF
There was a problem hiding this comment.
Also note a separate init is mostly useful for extract-and-expand constructions, whereas most KDFs are one-shot, so it would be nice to have something specific to the latter
|
Another important question: output size limits and fallibility. Should we have a How about a trait with an associated constant or typenum type that defines the maximum output size? |
|
I am assuming that "key stretching functions", e.g. Argon2, Scrypt and such, don't fall under this trait? |
|
@daxpedda I think it would be good to eventually support password-based KDFs. I think they wind up having a very similar API to other KDFs, to the point it might just be a marker trait and some usage guidelines. That said, it would probably be good to focus on traits for what's in https://github.com/rustcrypto/kdfs for now |
|
FWIW: I don't have much feedback for this kind of interface, but for OPAQUE we would like to have a trait for key stretching functions. |
Traits which provide an API for interacting with Key Derivation Functions.
We have several of these located at https://github.com/rustcrypto/kdfs and password-based KDFs at https://github.com/RustCrypto/password-hashes but the APIs for using these are typically just free functions, whereas traits could provide a common API.