From: "Stephan Müller" <smueller@chronox.de>
To: James Morris <jamorris@linux.microsoft.com>
Cc: "Mickaël Salaün" <mic@digikod.net>,
"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: Wed, 23 Jun 2021 19:27:53 +0200 [thread overview]
Message-ID: <8811360.37IJKxs2K1@positron.chronox.de> (raw)
In-Reply-To: <a4e1c071-32af-9650-e6fd-8943b3a79bb0@linux.microsoft.com>
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
next prev parent reply other threads:[~2021-06-23 17:28 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 [this message]
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
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=8811360.37IJKxs2K1@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.