[Cryptography] [RNG] on RNGs, VM state, rollback, etc.

[Bill Stewart]

At 09:36 AM 10/19/2013, Adam Back wrote:
>On Sat, Oct 19, 2013 at 10:33:34AM -0400, Theodore Ts'o wrote:
>>One of them was to do precisely this --- /dev/urandom now mixes in
>>salting information (ethernet MAC addresses, etc, via the new
>>interface add_device_randomness).  Zero entropy is indeed assessed,
>>and the main goal is to avoid the trivially easy case of shared primes
>>in the case where we fail to gather enough entropy.
>
>I know its obvious and you mentioned the risks, but this is in principle a
>band-aid or worse; it gives the illusion of entropy in the face of actually
>no entropy to an attacker who can readily obtain the serial numbers in
>question (eg because the MAC is broadcast on the LAN) or simply brute forced
>because the guid is while large, highly structured and sparse.

I'd kind of expect that "Zero entropy is assessed" is supposed to mean
"NOT giving the illusion of entropy", but that doesn't mean users 
will do that :-)
And sure, you need more entropy than that against a KGB-style attacker
(which, with another 10-20 years of Moore's law, means any script kiddie),
but at least it's protecting you against the
"all the VMs generate the same primes for their RSA key" problem,
which protects you against a whole class of attacks.

>It would seem safer to fail/stop and demand user action.

Demanding user action is really tough in a VM that hasn't connected 
to users yet;
anything you do is either going to go across a network or ask the host,
so you need an entropy gathering mechanism that can work with that.
If nothing else you can do something cheap like grab N = lowest 8-16 
bits of uandom,
run the urandom N times, grabbing timestamp entropy each time,
hoping to get a few more bits of real sloppiness.