Linux cryptographic layer development
 help / color / mirror / Atom feed
From: "Stephan Müller" <smueller@chronox.de>
To: noloader@gmail.com
Cc: LKML <linux-kernel@vger.kernel.org>, linux-crypto@vger.kernel.org
Subject: Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)
Date: Sat, 18 Mar 2017 17:36:36 +0100	[thread overview]
Message-ID: <1562063.6VeVDMHaV5@positron.chronox.de> (raw)
In-Reply-To: <CAH8yC8nHEQfZCf0j0rcW9KV-DNzkv-Sowch4ROK07HXzT5bFCA@mail.gmail.com>

Am Samstag, 18. März 2017, 14:43:18 CET schrieb Jeffrey Walton:

Hi Jeffrey,

> > I am not sure how this statement relates to the quote above. RDSEED is the
> > CBC-MACed output of the flip-flop providing the raw noise.
> > 
> > RDRAND is the output of the SP800-90A CTR DRBG that is seeded by the
> > CBC-MAC that also feeds RDSEED. Thus, RDSEED is as fast as the noise
> > source where RDRAND is a pure deterministic RNG that tries to be
> > (re)seeded as often as possible.
> > 
> > Both instructions are totally unrelated to the SP800-90A DRBG available to
> > the Linux kernel.
> 
> SP800-90A requires an entropy source to bootstrap the Hash, HMAC and
> CTR generators. That is, the Instantiate and Reseed functions need an
> approved source of entropy. Both RDRAND and RDSEED are approved for
> Intel chips. See SP800-90A, Section 8.6.5
> (http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf).

I am aware that SP800-90A makes the claim of having an approved noise source. 
But as of now, there is no such thing.

NIST is aware of that issue. To cover that issue during a FIPS 140-2 
validation, you have to prove your noise sources to be compliant to SP800-90B. 
I performed such noise source assessments as part of the FIPS 140-2 
validations of the Intel Sunrise Point or the Qualcomm HW DRBG FIPS 140-2 
validations. Also, I completed such assessments for the FIPS 140-2 validations 
of the legady /dev/random covering numerous Linux-based cryptographic modules 
over the last couple of years.

To get a glimpse of how such assessments for FIPS 140-2 are conducted, please 
have a look at the assessment [1] section 5.3.2.1 starting on page 72 in the 
lower half (note that I was the main author of this study). To be honest, the 
assessment in [1] section 5.5 was the main motivation for my LRNG 
implementation.

That said, [2] section 3.4.1, starting at page 34 bottom, you see the same 
SP800-90B test approach that was equally accepted by NIST during formal FIPS 
140-2 validations of other noise sources. Hence, I would conclude that my 
suggested implementation of the noise source is appropriate for a DRBG to be 
compliant to section 8.6.5 of SP800-90A.

But you mention a very important topic: is it and how is it ensured that the 
DRBG is appropriately seeded. This issue is discussed in [2] section 2.1 which 
explains the initial, minimal and full seeded stages of the DRBG.

[1] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/
ZufallinVMS/Randomness-in-VMs.pdf

[2] http://www.chronox.de/lrng/doc/lrng.pdf

Ciao
Stephan

      reply	other threads:[~2017-03-18 16:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10  8:21 [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1) Stephan Müller
2017-03-17 15:31 ` Jason A. Donenfeld
2017-03-18  8:18   ` Stephan Müller
2017-03-18 10:11 ` Jeffrey Walton
2017-03-18 13:31   ` Stephan Müller
2017-03-18 13:43     ` Jeffrey Walton
2017-03-18 16:36       ` Stephan Müller [this message]

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=1562063.6VeVDMHaV5@positron.chronox.de \
    --to=smueller@chronox.de \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noloader@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox