On Aug 25, 2010, at 4:37 PM, travis+ml-cryptogra...@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 majord...@metzdowd.com
