[Cryptography] cheap sources of entropy

[Arnold Reinhold]

On Mon, 27 Jan 2014 22:23 Bill Stewart <bill.stewart at pobox.com>
To: cryptography at metzdowd.com
Subject: Re: [Cryptography] cheap sources of entropy
Message-ID: <20140128062407.01B3C106B1 at a-pb-sasl-quonix.pobox.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

> At 07:10 AM 1/21/2014, Theodore Ts'o wrote:
>> [1] http://zsoltfabok.com/blog/2013/01/parkinsons-law/
>> I'm not sure whether the RNG is better characterized as the "bite
>> shed" or the "coffee for refreshments" as described in Parkinson's 3rd
>> chapter, "High Finance, or the Point of Vanishing Interest", but I
>> know one thing for sure.  It's not the 10 million pound nuclear
>> reactor.
> 
> It's clearly into bike shed territory, thus the endless discussion.
> We've all got ideas about the problem and how to fix it, or how it's 
> unfixable,
> or at least how somebody else's solution to it is clearly wrong wrong wrong,
> unlike the coffee case where we'd have all agreed on a good-enough solution
>         ("But I don't like coffee!" "Fine, we'll also order donuts 
> and tea." "Ok, whatever.")
> 

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 (https://en.wikipedia.org/wiki/RNG_attack#Prominent_examples) and we have every reason to believe it is being actively exploited by large security organizations. 

> I'd be tempted to take the Intel "NSA Inside" RNG, hash each 32 bits 
> down to 1,
> hash it in with any other available entropy, and call it a day.
> Probably simple parity calculation is as good as fancier hashes for that,
> but hash in the system clock if you'd like.
> Maybe use 128 bits instead of 32 if you don't have any other saved entropy.

If the Intel chip that you are using has its RNG cooked in ways that have been proposed, what you are suggesting will do you no good. The cook will still be able to recover the internal state of the faux-RNG and all your crypto will be worthless.

> 
> -- other comments on paint colours for the bike shed --
> There are lots of recommendations for what to do if you can add on hardware,
> such as accelerometers (much more useful for cellphones than 
> rack-mounted servers,
> which are kind of tough to wave around), USB cameras (if you can trust the USB
> on your VMware server), sound cards with or without microphones (ditto),
> but sometimes you just can't.  There's CPU timing randomness
> (not sure how random the low-order bits are in a virtual machine),
> clocks aren't all that random, though they can help you against replay attacks,
> and for a virtual machine you really need to do something to prevent
> everybody from using the same "entropy" seed in their identical images.

You are right that every RNG solution has limitations (for the record I suggested including a cellphone vibration motor to excite an accelerometer used on a server) and there is no one right answer. The best we can do is to use two or more independent sources, characterize each source well, implement them properly, and design our systems for maximum auditability consistent with security.

There are (at least) four reasons we keep having endless discussions about RNG: there are many possible solutions, there is no one solution that fits every situation, there are no good standards available (NIST SP800-90 ducks the hard questions), and people forget what was said before. 

Maybe it is time to build a Wiki that summarizes cryptography mailing list discussions on this and other topics.


Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140128/fc068036/attachment.html>