questions about RNGs and FIPS 140

[Nicolas Williams]

On Sat, Aug 28, 2010 at 07:01:18PM +1200, Peter Gutmann wrote:
> What matters to someone getting something evaluated isn't what NIST thinks or
> what one person's interpretation of the standard says, but what the lab does
> and doesn't allow.  Since what I reported is based on actual evaluations
> (rather than what NIST thinks), how can it be "factually incorrect"?

BTW, FIPS-140-2 is reasonable regarding RNGs: there are no approved
non-deterministic RNGs, and but non-deterministic RNGs may be used to
seed a deterministic RNG.  There are a few problems though:

a) nothing in the standard says anything about re-seeding nor seeding in
   the absence of TRNGs,
b) the standard speaks of "nondeterministic RNGs approved for use in
   classified applications" without referencing what such RNGs exist
   (and specifically stating that there are on approved
   non-deterministic RNGs),
c) Annex C (where approved RNGs are listed) is still a Draft.

On the plus side, one of the approved RNGs listed in the draft Annex C
(DRBG Special Publication 800-90) specifically addresses the entropy
pool concept, periodic reseeding with entropy from a non-deterministic
RNG (or from a chain of RNGs anchored by a non-deterministic RNG).

> >The fact is that all of the approved deterministic RNGs have places that you
> >are expected to use to seed the generator.  The text of the standard
> >explicitly states that you can use non-approved non-deterministic RNGs to
> >seed your approved deterministic RNG.
> 
> Yup, and if you look at some of the generators you'll see things like the use
> of a date-and-time vector DT in the X9.17/X9.30 generator, which was the
> specific example I gave earlier of sneaking in seeding via the date-and-time.
> Unfortunately one lab caught that and required that the DT vector really be a
> date and time, specifically the 64-bit big-endian output of time(), the
> Security 101 counterexample for how to seed an RNG.

X9.31 uses two seeds, one a date/time vector, the other a proper seed
vector.  X9.31 is in the FIPS-140-2 draft Annex C.

> In summary it doesn't matter what the standard says, it matters what the labs
> require, and that can be (a) often arbitrary and (b) contrary to what would
> generally be regarded as good security practice.

I would argue that if what you say is true then it derives from the
standard being underspecified.  In other words: what the standard says
(and doesn't) does matter, very much.  If different labs interpret
critical portions of the standard in significantly different ways, and
in some cases in ways that reduce security, then clearly the standard is
in need of updating.

The spec ought to describe acceptable PRNG seeding in the absence of
TRNGs (e.g., use a factory seed plus date/time and/or an atomically
incremented counter that is stored persistently), it should cover
virtual machines, and it should cover RNGs that are entropy pools
constructed out of TRNGs and PRNGs.

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com