questions about RNGs and FIPS 140

[Jerry Leichter]

On Aug 25, 2010, at 4:37 PM, travis+ml-cryptography at subspacefield.org  
wrote:
>
> I also wanted to double-check these answers before I included them:
>
> 1) Is Linux /dev/{u,}random FIPS 140 certified?
> No, because FIPS 140-2 does not allow TRNGs (what they call non- 
> deterministic).  I couldn't tell if FIPS 140-1 allowed it, but FIPS  
> 140-2 supersedes FIPS 140-1.  I assume they don't allow non- 
> determinism because it makes the system harder to test/certify, not  
> because it's less secure.
No one has figured out a way to certify, or even really describe in a  
way that could be certified, a non-deterministic generator.

> 3) Is determinism a good idea?
> See Debian OpenSSL fiasco.  I have heard Nevada gaming commission
> regulations require non-determinism for obvious reasons.

IPS doesn't tell you how to *seed* your deterministic generator.  In  
effect, a FIPS-compliant generator has the property that if you start  
it with an unpredictable seed, it will produce unpredictable values.   
Debian's problem was that it violated the "if" condition.  The  
determinism of the algorithm that produced subsequent values wasn't  
relevant.

> 4) What about VMs?
> Rolling back a deterministic RNG on those systems gives the same
> values unless/until you re-seed with something new to this iteration.

I'm not sure what you mean by "rolling back".  Yes, if you restart any  
deterministic RNG with a previously-used internal state, it will  
generate the same stream it did before.  This is true whether you are  
in a VM or not.

RNG's in VM's are a big problem because the "unpredictable" values  
used in the non-deterministic parts of the algorithms - whether you  
use them just for seeding or during updating as well - are often much  
more predictable in a VM than a "real" machine.  (For example, disk  
timings on real hardware have some real entropy, but in a VM with an  
emulated disk, that's open to question.)

We had a long discussion on this list a couple of weeks back which  
came to the conclusion that a hidden, instance-specific state, saved  
across reboots; combined with (fairly minimal) entropy at boot time;  
was probably a very good way to go.
                                                         -- Jerry

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