lkml.org 
[lkml]   [2021]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v1] crypto: Make the DRBG compliant with NIST SP800-90A rev1
Date
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


\
 
 \ /
  Last update: 2021-06-25 15:51    [W:0.072 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site