lkml.org 
[lkml]   [2017]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)
Date
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

\
 
 \ /
  Last update: 2017-03-18 17:37    [W:0.051 / U:1.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site