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


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