[147710] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (dj@deadhat.com)
Thu Oct 17 17:11:31 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <5D9D1764-5578-42A4-BBB1-4586B5F167D3@lrw.com>
Date: Thu, 17 Oct 2013 20:36:11 -0000
From: dj@deadhat.com
To: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
>
> More recently, David Johnston, who I gather was involved in the design of
> the Intel on-chip RNG, commented in a response to a question about
> malfunctions going undetected:
>
>> That's what BIST is for. It's a way to meet FIPS and SP800-90
requirements.
>
>
> Of course, with generators like the Linux /dev/random, we're in some
> intermediate state, with hardware components that could fail feeding data
> into software components.
>
Don't confuse the SP800-90 requirements for continuous testing and rest of
the necessary chip testing that all chips need. FIPS 140-2 imposes limits
on what passes through a FIPS boundary. This means that it is way easier
to do your chip testing using logic BIST contained within the FIPS
boundary than it is to try and pull full chip test through FIPS. You also
need the SP800-90 continuous tests implemented within the FIPS boundary.
You need to test your chips. FIPS forces you to use BIST.
You need to monitor your sources. SP800-90 forces you to use a particular
type of continuous monitoring.
These are quite separate things in type and style, but you have to do both.
In a FIPS compliant system with a software SP800-90 DRBG, I assume that
the FIPS boundary almost never coincides with the boundary of the SP800-90
implementation, so the rules and driving issues are quite different.
This has almost nothing to do with the Linux kernel random service which
does it's own thing very differently to NISTy RNGs.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
