[Cryptography] Random numbers only once

[John Denker]

On 02/03/2014 10:12 PM, Watson Ladd wrote:

> As DJB pointed out on another listhost, one only needs 256 random bits
> once, and can then use a PRF to generate an indefinite number forever.

I mostly agree with the sentiment.

To say the same thing in my own words:  We can agree that "most" needs 
can be met with a PRNG.  However, every PRNG needs to be seeded, which
means that at /some/ point a good HRNG is needed.

Let's be clear:  One can imaging a HRNG without a PRNG, but not vice
versa.  Contrary to what iang keeps saying, at /some/ point /some/
actual entropy is needed.

> It wouldn't be that hard to write to a defined block of a disk image
> these 32 random bytes.

Agreed.

This should be done as a routine part of the /provisioning/ process.

> Why does /dev/random not do this and so avoid blocking after startup?

The problem is, a lot of people make incredibly foolish assumptions
about RNGs.  Here are a few of the "greatest hits":

1) Starting with the correct assumption that a high-entropy seed
 must be available at /some/ point, certain implementers leap to 
 the incorrect assumption that a steady supply of entropy will
 "always" be available.

 It sounds ridiculous when said that way, but certain well-known
 RNG implementations really do embody the assumption that entropy 
 will "always" be coming in at some rate, possibly a small rate, 
 but nonzero.

 Sometimes this assumption is implicit and deeply buried in the
 code ... but sometimes it is blurted out quite explicitly.


2) People sometimes do foolish things in the name of "recovery
 from compromise".  Apparently the argument is that the PRNG
 is "better" if it recovers more quickly from compromise.  When
 carried to the extreme, this means that routine, unavoidable,
 non-critical use of /dev/urandom is tantamount to a denial-of-
 service attack against /dev/random, and against the critical
 upstream entropy sources that are called upon to feed /dev/random.

 This is particularly foolish given that it is predicated on an
 artificial, stylized threat model, namely a one-time passive
 capture of the PRNG state and nothing else.  In the real world, 
 there are also active attacks.  There are also ongoing passive
 attacks.  There are also attacks that capture a whole lot more
 than the PRNG state, including passwords and keys, such that
 reseeding the PRNG is verrrry far from sufficient to recover
 from the real compromise.


3) There are RNG implementers running around who don't understand
 what entropy is, or don't care.  It is easy to find "extract_entropy()"
 routines that extract no entropy, when used in the normal way.


4) A lot of people wildly underestimate how hard it is to properly
 build and operate a RNG.  They think they understand the problem,
 when they really don't.  When you tell them the PRNG is not being
 properly seeded, they get the brilliant idea of using the host's
 MAC address as the seed, as if the attacker could not possibly
 figure out the MAC address.  If you argue with them, they come up 
 with the brilliant idea of using the real-time clock, as if the 
 attacker could not possibly figure out what time it is.

 These arguments sometimes come from "official" package maintainers
 who are in a position to block upgrades to the widely-used distros.


5) There is a lot of mental inertia.   People assume that just
 because a certain RNG has been in use for years, it must have
 been well designed.  They assume that "somebody else" must have 
 thoroughly reviewed the code at some point.  They assume that 
 whatever assumptions were made originally must remain valid when
 the code is ported to new platforms, even wildly dissimilar 
 platforms.


6) People outside the crypto community wildly underestimate the
 importance of having a good RNG.   They are unaware of the lurid
 history of RNG failures.  Bug reports against the RNG system are 
 given near-zero priority.

=====================

These are all fixable problems.  The need to get fixed, pronto.
I'm reasonably optimistic that they can be fixed.