[Cryptography] RFC possible changes for Linux random device

Theodore Ts'o tytso at mit.edu
Tue Sep 16 12:02:08 EDT 2014


On Tue, Sep 16, 2014 at 10:37:34AM -0400, Jerry Leichter wrote:
> Agreed.  But let's also be more careful about attacks.
> 
> Suppose we implemented an AES-CTR PRNG, initialized using a TRNG.
> 
> - If, on the other hand, my crypto system can survive a break of AES
>(probably because it doesn't use AES at all - many systems rely on
>the security of AES *plus* the security of, say, RSA, and they are
>just as vulnerable to a break of AES), then I should *not* rely on
>this PRNG as my source of randomness.

We need to be even more careful about the attacks.  The vulnerability
of using cipher-based DRBG is quite different from using cipher using
a data encryption system.  So just because a cipher is vulnerable to
various chosen plaintext attacks, differential cryptanalysis, etc., it
doesn't follow that a cipher which is being used as a DRBG would also
be vulnerable.

It's also worth noting that even NDRBG's use some kind of cipher as
part of the whitning process.  For example Fortuna uses some kind of
cipher: AES, Serpent, Twofish, etc.  RDRAND uses AES as a whitener.
The only difference is how much entropy is harvested from hardware
sources.  If ratio of entropy harvested hardware sources is >= output
of the system, then it's considered a NDRBG.  If the amount of entropy
is < the output, then it's considered a DRBG.  The only question then
is how often the DRBG is reseeded from hardware-derived entropy.

Currently we are using the folded output of SHA-1 of the urandom pool
(with the pool mixed between each read).  For all of the weaknesses
that people have of SHA-1, the mode that we are use it is not one
where the currently known attacks are applicable.  But for those
people who are nevertheless paranoid, would anyone like to seriously
argue that using an AES-CTR based DRBG would be significantly
cryptographically weaker?

(Not that I'm all that worried about the details of crypto-level
attacks, to be honest.  I'm much more worried about making sure we can
reliably harvest hardware-derived entropy, especially on embedded
Linux platforms such as the MIPS-based systems used in most home
routers, the ARM processors used on most handsets and tablets, etc.
People who are focused too much on the cryptography are missing the
forest for the trees, IMHO.)

> I don't see why this is wasteful.  As Ts'o proposes it, only those
> processes that happen to use it get it.

And the processes that happen to use /dev/urandom today are generally
incredibly profligate already.  For example, until recently NSS used
fopen() on /dev/urandom, which immediately pulled 4k into a memory
buffer (and anyone want to guess whether the stdio buffer was properly
cleared afterwards?  I'll give you three guesses, and the first two
don't count.)

> The only thing I would add to his proposal is a system call to
> securely destroy the current process PRNG data structure, resetting
> the process to the "no PRNG" state.

That seems reasonable.

> I'd also suggest that the PRNG state be destroyed on exec - a new
> program should not be able to get any information about the "random
> number" some *other* program generated in the past, even if they
> happen to live in the same process.

That was in the original proposal.  The PRNG state would be cleared on
exit, exec, and fork (in the child thread/process).

Cheers,

					- Ted


More information about the cryptography mailing list