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
