[Cryptography] Random numbers only once

[Theodore Ts'o]

On Fri, Feb 21, 2014 at 01:12:20AM -0500, John Kelsey wrote:
> > Translated:
> > 
> >  If some obscure system component the user has never heard of before doesn't
> >  have enough zarglemorf, it has the stop the system from functioning.
> > 
> > It's fair enough to make this a theoretical requirement, but it'll never fly
> > in practice.
> 
> Well, it's not a requirement for 99%+ of uses of random numbers.
> But before you generate a crypto key, you need at least 128 or so
> bits of entropy that haven't been used to generate any other
> outputs, so that you can seed an RNG.  If you don't have that, and
> you seed the RNG and generate the crypto key anyway, you get
> something that looks just like real crypto, except that there are
> attackers who can sign messages coming from you or read your
> encrypted mail, and every now and then some smartass academic will
> be factoring thousands of your devices' RSA keys because they all
> share primes.

Huh?  What are you including your sample set "uses of random numbers"?
And when you mean "crypto key", are you making any distinctions
between some random session key used for some bullshit TCP session
(which might or might not have any real security impact if it leaks,
other than a "let's encrypt everything to give the NSA a hard time)?
When you say "crypto key", are you including other cryptographic use
cases, such as IV's?

Given that most users aren't running monte carlo simulations, I'd
argue that 99% of the users of /dev/urandom on Linux *are* using it
for cryptographic purposes for one sort or another.  And if we move to
a world where we encrypt everything, then if we arbitrarily block in
early boot, users will *not* be happy, and device vendors will patch
out the code.

So from a practical engineering perspective, I'd much rather grab as
much stuff as possible which hopefully won't be easily monitored by a
remote attacker in Fort Meade (i.e., grab radio signal strength info
from the wifi and cell radios, etc.) and make the random pool be
seeded with as much stuff as possible which is hard for attackers to
guess (it would be nice to be able to prove with 100% certainty that
it is impossible for an attacker to compromise or guess, but I'd also
like to be the sole winner of the $440 million dollar powerball
loterry --- and I think the latter is more likely).

My compromise to this is to make /dev/random to be as conservative as
possible, and let it block, on the theory that there will be cases
where you are willing to block if the system doesn't think the random
poll is sufficiently well seeded.  However, I'm well aware that I will
be attacked from both sides --- on the one side, having something that
will block at all, and on the other, for having something which
application authors and device vendors will actually be willing to
*use*.

> The best answer I see to this is a hardware entropy source built
> into everything, combined with whatever entropy can be collected in
> time to seed a good DRBG.

And if anyone has any suggestions about how to influece or force ARM
SOC vendors to include a hardware entropy source, I'd love to hear
them.  I even have some friends at Linaro who might be willing to help
to bring some of these suggestions into practice.  Anyone have any
ideas short of compromising photographs of CEO's of companies like
Qualcomm and Samsung?  :-)

						- Ted