[lkml]   [2019]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function
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.


 \ /
  Last update: 2019-01-14 20:19    [W:0.134 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site