From: "Stephan Müller" <smueller@chronox.de>
To: "James Morris" <jamorris@linux.microsoft.com>,
"Mickaël Salaün" <mic@digikod.net>
Cc: "David Miller" <davem@davemloft.net>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"John Haxby" <john.haxby@oracle.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Simo Sorce" <simo@redhat.com>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
"Mickaël Salaün" <mic@linux.microsoft.com>,
hpa@zytor.com, tytso@mit.edu
Subject: Re: [PATCH v1] crypto: Make the DRBG compliant with NIST SP800-90A rev1
Date: Fri, 25 Jun 2021 15:50:09 +0200 [thread overview]
Message-ID: <3789849.nkhAASfZ5y@positron.chronox.de> (raw)
In-Reply-To: <248b1aae-effc-f511-03af-65a71f176cf1@digikod.net>
Am Freitag, 25. Juni 2021, 13:09:26 CEST schrieb Mickaël Salaün:
Hi Mickaël,
[...]
>
> > - applies an entropy_input len of 512 bits during initial seeding
> >
> > - applies a nonce of 128 bits during initial seeding
> >
> > entropy_input == <384 bits get_random_bytes> || <256 bits Jitter RNG>
>
> We think that using "<384 bits get_random_bytes> || " makes this DRBG
> non-compliant with SP800-90A rev1 because get_random_bytes doesn't use a
> vetted conditioning component (but ChaCha20 instead):
>
> SP800-90Ar1, section 8.6.5 says "A DRBG mechanism requires an approved
> randomness source during instantiation and reseeding [...]. An approved
> randomness source is an entropy source that conforms to [SP 800-90B], or
> an RBG that conforms to [SP 800-90C] − either a DRBG or an NRBG".
> The FIPS 140-2 Implementation Guidance
> (https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-p
> rogram/documents/fips140-2/fips1402ig.pdf), section 7.19 says "As of
> November 7, 2020, all newly submitted modules requiring an entropy
> evaluation must demonstrate compliance to SP 800-90B". In resolution 3 it
> says "all processing of the raw data output from the noise sources that
> happens before it is ultimately output from the entropy source *shall*
> occur within a conditioning chain". Data from get_random_bytes may come
> from multiple noise sources, but they are hashed with ChaCha20.
> In resolution 6 it says "a vetted conditioning component may optionally
> take a finite amount of supplemental data [...] in addition to the data
> from the primary noise source", which would be OK if get_random_bytes
> used a vetted algorithm, but it is not the case for now.
You cite the right references, I think the interpretation is too strict.
The specifications require that
a) The DRBG must be seeded by a 90B entropy source
b) The DRBG must be initially seeded with 256 bits of entropy plus some 128
bit nonce
We cover a) with the Jitter RNG and b) by pulling 384 bits from it.
The standard does not forbit:
c) the entropy string may contain data from another origin or it contains a
larger buffer
d) the actual entropy distribution in the entropy string being not an
equidistribution over the entire entropy string
Bullet d) implies that it is perfectly fine to have entropy distribution begin
loopsided in the entropy string.
Bullet c) implies that other data can be provided with the entropy string.
With that, to be 90A/B compliant, you interpret that the Jitter RNG provides
all entropy you need and credit the entropy from get_random_bytes with zero
bits of entropy.
Note, if you look into the implementation of the DRBG seeding, the different
input strings like entropy string or data without entropy like personalization
string are simply concatenated and handed to the DRBG. As the Jitter RNG and
get_random_bytes data is also concatenated, it follows the concepts of 90A.
If you look into the draft 90C standard, it explicitly allows concatenation of
data from an entropy source that you credit with entropy and data without
entropy - see the crediting of entropy of multiple entropy sources defined
with "Method 1" and "Method 2" in the current 90C draft.
This ultimately allows us to have an entropy string that is concatenated from
different entropy sources. If you have an entropy source that is not 90B
compliant, you have to credit it with zero bits of entropy in the entropy
analysis. Thus, only the entropy source(s) compliant to 90B must provide the
entire entropy as mandated by 90A.
After having several discussions with the Entropy Working group sponsored by
NIST that included also representatives from the NIST crypto technology group,
there was no concern regarding such approach.
This approach you see in the current DRBG seeding code is now taken for
different FIPS validations including FIPS validations that I work on as a FIPS
tester as part of my duties working for a FIPS lab. My colleagues have
reviewed the current kernel DRBG seeding strategy and approved of it for other
FIPS validations.
Ciao
Stephan
next prev parent reply other threads:[~2021-06-25 13:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 12:07 [PATCH v1] crypto: Make the DRBG compliant with NIST SP800-90A rev1 Mickaël Salaün
2021-06-23 14:22 ` Stephan Mueller
2021-06-23 17:00 ` James Morris
2021-06-23 17:27 ` Stephan Müller
2021-06-23 18:04 ` Mickaël Salaün
2021-06-23 19:10 ` Stephan Mueller
2021-06-24 10:13 ` Mickaël Salaün
2021-06-24 11:50 ` Stephan Mueller
2021-06-25 11:09 ` Mickaël Salaün
2021-06-25 13:50 ` Stephan Müller [this message]
2021-06-25 14:53 ` Mickaël Salaün
2021-06-23 20:49 ` H. Peter Anvin
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=3789849.nkhAASfZ5y@positron.chronox.de \
--to=smueller@chronox.de \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=jamorris@linux.microsoft.com \
--cc=john.haxby@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mic@digikod.net \
--cc=mic@linux.microsoft.com \
--cc=simo@redhat.com \
--cc=tytso@mit.edu \
/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).