Am Montag, 14. Januar 2019, 18:53:16 CET schrieb Eric Biggers: Hi Eric, > > I would not suggest this, because that rounds contrary to the concept of > > the kernel crypto API IMHO. The caller has to provide the wrapping > > cipher. It is perfectly viable to allow a caller to invoke a specific > > keyed message digest. > Sure, but it would not conform to the HKDF specification. Are you sure it > is okay to specify an arbitrary keyed hash? Technically, I see no issue why this should not be possible. You see that with the SP800-108 KDF implementations where using CMAC is perfectly legal (and which I also test). Though, using another keyed hash implementation like CMAC is not covered by the HKDF spec. If a caller would use hkdf(cmac(aes)), it would produce cryptographically strong values. Though this implementation does not conform to any standard. I do not think we should prevent a caller to select such combination in the kernel crypto API. IMHO there would even be valid reasons why one would use cmac(aes) for a kdf. For example, when you would want to use a hardware AES which somehow also employs a hardware key that is inaccessible to software in order to tie the KDF result to the local hardware. This could even be a valid use case for Ext4 FBE encryption where you derive a key. The KDF could be used to link the derived key to the local hardware to prevent the encrypted data could be copied to another system and decrypted successfully there. Ciao Stephan
