Hkdf enhancement#69
Conversation
| ) -> Result<Self::Prk, HkdfError> { | ||
| // When salt is absent, RFC 5869 uses HashLen zero bytes as the HMAC key. | ||
| // Buffer covers standard algorithms up to SHA-512 (64 bytes). | ||
| // Ideally this would be H::Algorithm::MAX_OUTPUT_LEN once const_trait_impl stabilises. |
There was a problem hiding this comment.
We don't need const_trait_impl for that if it is an associated const -- we can just introduce that associated constant.
Then InvalidOutputLength is back to returning inconsistent lengths, and as we start just using the underlying type as the only truth (no longer adding own knowledge), I don't think there are any cases left for it.
|
|
||
| pub trait HkdfProvider { | ||
| /// HKDF-Extract (RFC 5869): returns a 32-byte pseudorandom key. | ||
| type Algorithm: HmacAlgorithm; |
There was a problem hiding this comment.
Can't we just say that trait HkdfProvider: HmacProvider, and then not use an own Algorithm at all but just everywhere use <Self as HmacProvider>::Algorithm?
| type Algorithm: HmacAlgorithm; | ||
| /// Opaque input keying material. May be constructed from a DH shared secret | ||
| /// without the raw bytes ever being user-visible. | ||
| type Ikm: ?Sized; |
There was a problem hiding this comment.
Not having any From<[u8]> for Ikm and AsRef<[u8]> for Okm means that users depend on knowing the concrete type -- which they can because of the blanket implementation, but then, we could just also not have types here until we start differentiating. (And that really doesn't need to be now.)
2 participants
Some points raised in the #55
It changes the HKDF to not only work with HMAC-SHA256, but with any HMAC.
Improve the comments a bit