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: <8811360.37IJKxs2K1@positron.chronox.de>
Date:   Wed, 23 Jun 2021 19:27:53 +0200
From:   Stephan Müller <smueller@...onox.de>
To:     James Morris <jamorris@...ux.microsoft.com>
Cc:     Mickaël Salaün <mic@...ikod.net>,
        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 Mittwoch, 23. Juni 2021, 19:00:29 CEST schrieb James Morris:

Hi James,

> On Wed, 23 Jun 2021, Stephan Mueller wrote:
> > > These changes replace the use of the Linux RNG with the Jitter RNG,
> > > which is NIST SP800-90B compliant, to get a proper entropy input and a
> > > nonce as defined by FIPS.
> > 
> > Can you please help me understand what is missing in the current code
> > which
> > seemingly already has achieved this goal?
> 
> The advice we have is that if an attacker knows the internal state of the
> CPU, then the output of the Jitter RNG can be predicted.

Thank you for the hint. And I think such goal is worthwhile (albeit I have to 
admit that if an attacker is able to gain the internal state of a CPU, I would 
assume we have more pressing problems that a bit of entropy).

Anyways, the current code does:

- in regular mode: seed the DRBG with 384 bits of data from get_random_bytes

- in FIPS mode: seed the DRBG with 384 bits of data from get_random_bytes 
concatenated with 384 bits from the Jitter RNG

If I understand the suggested changes right, I would see the following changes 
in the patch:

- in the regular case: 640 bits from get_random_bytes

- in FIPS mode: 256 bits of data from get_random_bytes concatenated with 384 
bits from the Jitter RNG

So, I am not fully sure what the benefit of the difference is: in FIPS mode 
(where the Jitter RNG is used), the amount of data pulled from 
get_random_bytes seems to be now reduced.

Maybe I miss a point here, but I currently fail to understand why the changes 
should be an improvement compared to the current case.

Ciao
Stephan