3

I looked at the questions here and here.

This then piqued my interest as I've recently been involved with looking into FIPS compliance, and in my vm environment /dev/urandom compliance testing generates data like this:

[admin@xxx~]$ cat /dev/urandom | rngtest -c 5000
rngtest 2
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 100000032
rngtest: FIPS 140-2 successes: 4998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.210; avg=63.902; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=2.477; avg=123.448; max=157.632)Mibits/s
rngtest: Program run time: 2277143 microseconds

The thing missing from these questions, is how bad is bad? Do we have firm numbers that dictate statistical compliance?

How badly does moving to a virtual machine harm entropy?

Community
  • 1
avgvstvs
  • 940
  • 1
  • 7
  • 19

1 Answers1

7

Statistical tests like the one you use cannot detect whether /dev/urandom is good or bad on a specific machine.

Specifically, /dev/urandom runs a cryptographically secure PRNG. From a given initial internal state (the "seed"), it produces an arbitrarily long stream of seemingly random bytes. The PRNG being cryptographically secure means that for an attacker to actually predict the next bit with probability better than 1/2, he MUST have guessed the exact internal state (down to the last bit); otherwise, he has nothing.

The risk of /dev/urandom in a VM relates to the theoretical possibility of the attacker being able to guess that state, since the state is fed from hardware sources and a VM has no true hardware, only emulated hardware. However, this requires an intelligent attacker that perfectly knows that the PRNG is the one usd by /dev/urandom on this specific machine, and the attacker purposely tries potential internal states based on what he knows about the emulated hardware and what the OS extracts as "random seed" from that hardware. Your rngtest does nothing of the sort; it runs basic statistical tests to see whether there are biases in a 100 Mbits stream.

To summarize: rngtest does not test the important thing, which is how much the seed is hard to guess by an intelligent attacker. Instead, rngtest measures how well the cryptographically secure PRNG algorithm is indeed cryptographically secure; and it does so only basically (it cannot see anything except the most obvious biases). By nature, rngtest cannot detect any VM-related issue with /dev/urandom (and, correspondingly, it is quite useless to run it).

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • So in answering the concrete question, "How badly does moving to a virtual machine harm entropy?" Its essentially subjective due to the total # of possible bits we lose in the move? – avgvstvs Oct 17 '14 at 19:46
  • 5
    In general, VM are fine because Linux distributions keep a random seed across reboots (it is part of what happens in the boot scripts) so as long as enough entropy was gathered during installation, you will have strong randomness forever. What can really hurt VM is snapshots/cloning: if you clone a VM then both machines will start with the same internal state, then slowly diverge. The interesting point is how fast they diverge; we currently lack data on that subject. – Tom Leek Oct 17 '14 at 19:56