[Cryptography] RFC possible changes for Linux random device

Theodore Ts'o tytso at mit.edu
Sat Sep 13 21:03:10 EDT 2014


On Sat, Sep 13, 2014 at 03:22:07PM -0700, John Denker wrote:
> In the spirit of covering all the bases, I would like
> to mention but /not/ advocate one further item:
> 
> x) rapidly recover from compromise of the PRNG internal
>  state.
> 
> For years, the legacy "standard" random.c has been
> obsessed with this goal, out of proportion to its
> actual practical importance, to the great detriment 
> of other goals including item (8).

Funny thing; when many academics write papers criticize the Linux
random driver, it's often because they don't think we *still* don't do
a good enough job by their lights.

And then there is the camp who believes that once you gather 256 bits
or so of "true randomness", all you need to do is just crank a DRBG,
and the rest is all just mummery, and I get mocked/criticized/told I'm
stupid by that crowd too.

Which is OK.  Over time, you learn how to have a thick skin when
people deliver mutually conflicting criticisms.  :-)

But this is one additional reason why I tell people that every single
change should be broken apart, and individually justified.  Because
there are many different religions about generating random numbers,
and they often hold conflicting viewpoints about what is important and
what is not important.  So by splitting out each change individually,
and making the rule be that each change should not make the system any
worse --- understanding fully that different people who are reviewing
the code will have their own definition of when a tradeoff is "worse",
means that if we can satisfy everyone, then it's probably a good
change.  :-)


I'll also add that improving boot-time entropy is the hard part; and
it has nothing to do with changing the crypto.  It has to do much more
with passing good seed information from the bootloader, so we can get
high-grade entropy at the time when we need to do the kernel ASLR ---
which means the bootloader needs to read the entropy state out of some
NVRAM, or out of the file system, and pass it to the kernel early boot
code.  It means working with individual device drivers and hardware
manufacturers to be able to harvest data values which are
unpredictable to different classes of attackers.  (i.e., getting
signal strength and bit error rates from the various radios in a
handset; which might not be *secret*, but given that someone in Fort
Meade might know whether the cell phone in someone's knapsack is
located below the desk or on top of the desk, might give a one or two
bits of extra entropy, etc.)

This is all hard stuff, and it's a lot easier than replacing the hash
algorithm used by the output function, etc.  It's also much less
glamorous, and very architecture specific.  

Cheers,

					- Ted

P.S.  Oh, and if anyone can get the ARM architecture folks to specify
a cycle counter which is guaranteed to be there, or at the very least,
won't crash the SOC if you try to use it and it's not there --- which
is why Linux doesn't try to use the cycle counter at all on most ARM
platforms, even though it's often present (it's just that it's not
guaranteed by the ARM architecture, and if you guess wrong, the
results are catastrophic) --- that would be awfully nice.  But again,
you'll see that all of the really important stuff has a lot less to do
about cryptography, and a lot more about engineering and politics and
negotiating with hardware vendors who are worried about shaving
millicents off of their BOM cost....



More information about the cryptography mailing list