The specific problem is when an application is using HKDF but it doesn't know at compile time a key it's going to need -- for example it needs a key that exactly matches the data it has so that it can XOR it.
The task is to add an API to HKDF-Expand that takes in an N and returns a Vec of length N filled with OKM. This API would probably more closely match the API in the RFC than what we have now, but would need to be guarded with #[cfg(feature = "alloc")].
This new API will need a doc note:
/// 🚨 Security Consideration 🚨
///
/// This OutputKeyingMaterial is returned as a [Vec<u8>] not as a [KeyMaterial], which means that it does not get
/// any of the protections offered by the [KeyMaterial] struct. The caller is responsible for making sure that it
/// doesn't get logged, that it gets zeroized on drop, and tracking the [SecurityStrength] of the HKDF instance that
/// generated it (if that's relevant to the application).
The specific problem is when an application is using HKDF but it doesn't know at compile time a key it's going to need -- for example it needs a key that exactly matches the data it has so that it can XOR it.
The task is to add an API to HKDF-Expand that takes in an N and returns a Vec of length N filled with OKM. This API would probably more closely match the API in the RFC than what we have now, but would need to be guarded with
#[cfg(feature = "alloc")].This new API will need a doc note: