-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abstract Hkdf and HkdfExtract over hmac::Mac #80
Comments
Sounds good to me. It would be nice to be able to support hardware accelerators. |
Note that HKDF is defined in terms of HMAC. So I don't think it will be correct to use the AFAIK HMAC is usually supported in HSM-like hardware to protect keys from leaking, not for efficiency sake. Can you provide an example of hardware which you would like to target? |
Good point, an I'm not following the block-level API comment. The code only seems to use slices. However something to note is that the current implementation optimizes by reusing the core. An implementation that doesn't permit this (hardware implementations usually don't) would just define the core to be the pseudo random key and not precompute anything. I sadly cannot provide an example hardware. But yes this is not about performance. (I'm currently on vacations for 3 weeks so might not be able to reply until then.) |
When I say "cryptographic accelerator" I mean TPM/SEP-like cryptographic coprocessor, and yes one of its main purposes of the kind I have in mind is to airgap and provide access control around keys including preventing exfiltration of the raw key material, but also such coprocessors include fixed functions of various cryptographic algorithms that run faster than the software equivalent on an MCU, so it's a little of both. I have one device that works this way with a baked-in device unique hardware key, however we did not wrap the HMAC functionality it provides, but instead we wrapped the device unique keyed AES functionality and use that to store the encryption of the base derivation key which we use to initialize HKDF, which works too. But also, I maintain crates like https://docs.rs/yubihsm/latest/yubihsm/client/struct.Client.html#method.sign_hmac It would need a sort of proxy type which knows the key ID a priori to implement a
Well it'd be really nice to completely decouple |
See how the
Note that for HKDF we need an update-based API. If YubiHSM provides only whole message signing API, then a wrapper would need to assemble a full message on heap, which will be somewhat inefficient. |
It's probably simpler if I write a PR when I'm back in 3 weeks. There looks like there is a misunderstanding on what is being achieved here, since your comments don't seem to reply to what I say. Code is probably easier to understand. |
Sorry for the very long delay, but I finally got time to get to this. I've created #82 to show an example of what I mean. Here are the main points:
|
I might be missing something about the rational behind the
HmacImpl
sealed trait (like some implicit invariant), but I'm wondering whyHkdf
andHkdfExtract
are not parametrized byhmac::Mac
instead. This trait already providesOutputSizeUser
.This would be useful when someone has both a
Digest
and aMac
hardware implementation and would like to compute HKDF using thatMac
hardware implementation instead of using theSimpleHmac
software implementation on top of theDigest
hardware implementation.The text was updated successfully, but these errors were encountered: