linux-kernel - Re: [PATCH v1] crypto: Make the DRBG compliant with NIST SP800-90A rev1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3789849.nkhAASfZ5y@positron.chronox.de>
Date:   Fri, 25 Jun 2021 15:50:09 +0200
From:   Stephan Müller <smueller@...onox.de>
To:     James Morris <jamorris@...ux.microsoft.com>,
        Mickaël Salaün <mic@...ikod.net>
Cc:     David Miller <davem@...emloft.net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        John Haxby <john.haxby@...cle.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Simo Sorce <simo@...hat.com>, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Mickaël Salaün <mic@...ux.microsoft.com>,
        hpa@...or.com, tytso@....edu
Subject: Re: [PATCH v1] crypto: Make the DRBG compliant with NIST SP800-90A rev1

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