lkml.org 
[lkml]   [2019]   [Jan]   [13]   [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 Samstag, 12. Januar 2019, 10:55:35 CET schrieb Herbert Xu:

Hi Herbert,

> On Fri, Jan 11, 2019 at 09:12:54PM -0800, Eric Biggers wrote:
> > Hi Stephan,
> >
> > On Fri, Jan 11, 2019 at 08:10:39PM +0100, Stephan Müller wrote:
> > > The RFC5869 compliant Key Derivation Function is implemented as a
> > > random number generator considering that it behaves like a deterministic
> > > RNG.
> >
> > Thanks for the proof of concept! I guess it ended up okay. But can you
> > explain more the benefits of using the crypto_rng interface, as opposed
> > to just some crypto_hkdf_*() helper functions that are exported for
> > modules to use?
> I agree. I see no benefit in adding this through the RNG API as
> opposed to just providing it as a helper. If some form of hardware
> acceleration were to eventuate in the future we could always revisit
> this.

The advantages for using the kernel crypto API to add KDFs as opposed to
adding helper wrappers are the following in my view:

- employment of the kernel crypto API testmgr - invocation of the testmgr is
transparent and thus already provided without any additional code to link to
it

- FIPS 140-2 compliance: To mark a KDF as FIPS 140-2 approved cipher, it must
be subject to a known-answer self test (implemented by the testmgr) as well as
to an enforcement of the integrity check verification. In FIPS 140-2 mode, the
kernel crypto API panic()s when a kernel crypto API module is loaded and its
signature does not check out. As this is only relevant for crypto modules (and
not arbitrary other kernel modules), this is implemented with the invocations
the crypto_register_alg as well as crypto_register_template functions. Thus,
when using a wrapper code to implement the KDF, they can per definition not be
FIPS 140-2 approved.

- The invoker of a KDF has one consistent API. This implies that the KDF
selection now becomes more of a "configuration" choice. For example, when you
look at the KDF use case for the keys subsystem (security/keys/dh.c),
selecting the type of KDF would only necessitate a change of a string
referencing the KDF. A lot of people somehow favor the extract-and-expand KDFs
over the traditional KDFs. Now, that the RFC5869 HKDF is also approved as per
SP800-56A rev3, I could see that folks may want to switch to HKDF for the key
management. When we have a common API, this choice could even be left to the
caller.

The question may arise why to plug the KDFs into RNGs. The answer is quite
simple: KDFs are a form of random number generator. In that they take some
input for initialization (aka seed, salt, key, personalization string). Then
they produce pseudo-random bit sequences of arbitrary length. Possibly the
generation operation can be modified by providing some additional input to be
used by the generation process (aka label, context, info string, additional
information string). Thus, the RNG interface is a natural fit for the KDFs.

Ciao
Stephan


\
 
 \ /
  Last update: 2019-01-13 08:57    [W:0.117 / U:4.716 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site