[Cryptography] Random numbers only once
jsd at av8n.com
Tue Feb 4 02:17:05 EST 2014
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.
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,
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
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.
More information about the cryptography