[Cryptography] cheap sources of entropy

[James A. Donald]

On 2014-01-29 04:31, Arnold Reinhold wrote:
> Nice analogy, but you both have it backwards. SHA2 vs SHA3, AES vs
> Salsa20 and RSA vs ECC are the bike shed/refreshment committee.  RNG is
> the $10 billion nuclear reactor waiting to blow up. At the present time
> there is no practical attack on the standard crypto algorithms, but RNG
> is a single point of failure that has shattered crypto security in
> practice many times

We do, however, know how to do RNG right.  We just don't do it right.

Use many, many different entropy sources, even ones that are known to 
suck.  The attacker cannot predict or control all of them.

Accumulate at least 128 bits of entropy before doing anything that 
requires randomness, and since you cannot trust how random your sources 
are, accumulate a lot more than 128 bits.  This does not in fact take 
very long at all, for example clock skew between the cpu clock and timer 
clock, hard drive turbulence, etc.

If your device likely has a solid state drive, so no hard drive 
turbulence, then it likely has lots of hardware sources of thermal noise 
and quantum noise, as for example the android phone.

Between boots, store previously acquired randomness.  On OS install, 
seed the store.

Once you have more than 128 bits of randomness, use it to seed a pseudo 
random number generator with a lot of internal state.

Output from the random number generator should give no clue as to the 
internal state.  Either take a cryptographically one way hash of the 
output, or use a random number generator whose output is believed to 
give no clue as to the internal state.   Having a lot of internal state 
helps render any clues less useful.

 From time to time, stir more randomness into the pseudo random number 
generator *in* *greater* *than* *128* *bit* *chunks*, not in smaller 
amounts.

Virtual machines have less access to true randomness, so the underlying 
real machine should provide them the output of its real random number 
generator.

This is, of course, not what we are in fact doing.

And whenever cryptographers complain "should do this right" the answer 
is "that would break lots of existing software, we need to be bug 
compatible"

So add a new source of cryptographic randomness, done right.  Call it 
xrandom.