From: "Stephan Müller" <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@kernel.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Andy Lutomirski <luto@amacapital.net>,
"Lee, Chun-Yi" <joeyli.kernel@gmail.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
keyrings@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Chen Yu <yu.c.chen@intel.com>, Oliver Neukum <oneukum@suse.com>,
Ryan Chen <yu.chen.surf@gmail.com>,
David Howells <dhowells@redhat.com>,
Giovanni Gherdovich <ggherdovich@suse.cz>,
Randy Dunlap <rdunlap@infradead.org>,
Jann Horn <jannh@google.com>, Andy Lutomirski <luto@kernel.org>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function
Date: Sun, 13 Jan 2019 08:56:32 +0100 [thread overview]
Message-ID: <9795894.APlZEWIbOH@positron.chronox.de> (raw)
In-Reply-To: <20190112095535.36rh3ptnrf7yxacv@gondor.apana.org.au>
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
next prev parent reply other threads:[~2019-01-13 7:57 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190103143227.9138-1-jlee@suse.com>
[not found] ` <1894062.aDvIuj92vB@tauon.chronox.de>
[not found] ` <20190109082103.GA8586@sol.localdomain>
2019-01-11 19:08 ` [PATCH 0/6] General Key Derivation Function Support Stephan Müller
2019-01-11 19:09 ` [PATCH 1/6] crypto: add template handling for RNGs Stephan Müller
2019-01-11 19:10 ` [PATCH 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller
2019-01-12 5:27 ` Eric Biggers
2019-01-14 9:31 ` Stephan Müller
2019-01-11 19:10 ` [PATCH 3/6] crypto: kdf - add known answer tests Stephan Müller
2019-01-12 5:26 ` Eric Biggers
2019-01-14 9:26 ` Stephan Müller
2019-01-11 19:10 ` [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function Stephan Müller
2019-01-12 5:12 ` Eric Biggers
2019-01-12 9:55 ` Herbert Xu
2019-01-13 7:56 ` Stephan Müller [this message]
2019-01-13 16:52 ` James Bottomley
2019-01-14 9:30 ` Stephan Müller
2019-01-14 17:53 ` Eric Biggers
2019-01-14 18:44 ` Stephan Mueller
2019-01-11 19:10 ` [PATCH 5/6] crypto: hkdf - add known answer tests Stephan Müller
2019-01-12 5:19 ` Eric Biggers
2019-01-14 9:25 ` Stephan Müller
2019-01-14 17:44 ` Eric Biggers
2019-01-11 19:11 ` [PATCH 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller
2019-01-16 11:06 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Müller
2019-01-16 11:07 ` [PATCH v2 1/6] crypto: add template handling for RNGs Stephan Müller
2019-01-16 11:08 ` [PATCH v2 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller
2019-01-16 11:08 ` [PATCH v2 3/6] crypto: kdf - add known answer tests Stephan Müller
2019-01-16 11:08 ` [PATCH v2 4/6] crypto: hkdf - HMAC-based Extract-and-Expand KDF Stephan Müller
2019-01-16 11:09 ` [PATCH v2 5/6] crypto: hkdf - add known answer tests Stephan Müller
2019-01-16 11:09 ` [PATCH v2 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller
2019-01-28 10:07 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Mueller
2019-01-30 10:08 ` Herbert Xu
2019-01-30 14:39 ` Stephan Mueller
2019-02-08 7:45 ` Herbert Xu
2019-02-08 8:00 ` Stephan Mueller
2019-02-08 8:05 ` Herbert Xu
2019-02-08 8:17 ` Stephan Mueller
2019-02-19 5:44 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9795894.APlZEWIbOH@positron.chronox.de \
--to=smueller@chronox.de \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=ggherdovich@suse.cz \
--cc=herbert@gondor.apana.org.au \
--cc=jannh@google.com \
--cc=joeyli.kernel@gmail.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=oneukum@suse.com \
--cc=pavel@ucw.cz \
--cc=rafael.j.wysocki@intel.com \
--cc=rdunlap@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=yu.c.chen@intel.com \
--cc=yu.chen.surf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).