[Cryptography] RFC possible changes for Linux random device

[Theodore Ts'o]

On Tue, Sep 16, 2014 at 02:34:14PM -0700, John Gilmore wrote:
> 
> Wouldn't it be simpler to make each open of /dev/urandom start a
> different stream of PRNG results, by hanging the state from the
> open-files structure rather than from the task structure?

Sure, that would work too; and that would certainly be simpler on a
number of levels.  In that case I *would* have to worry about what
happens if the file descriptor is inherited across exec's, although so
long as there is proper locking, it wouldn't be catastrophic for
multiple processes to share the same DRBG.  But I suppose we could
argue that it should be CLOEXEC enabled by default.

> BTW, I don't see why the getrandom() implementation posted to the
> linux kernel mailing list arbitrarily limits the caller to 256 bytes
> of random numbers.  It returns "EINVAL", defined as "The buflen value
> was invalid", but nothing in the interface spec says that values
> greater than the arbitrary number of 256 bytes are invalid.

We don't limit the caller to 256 bytes.  The OpenBSD getentropy(2)
system call does do that, and I was considering adding that at one
point, but after some discussion, we decided against following that
design for Linux.

> And given John Denker's concerns about retaining entropy, shouldn't
> the caller be able to explicitly state how much entropy they want to
> consume?  E.g. "Give me 192 bits of entropy and fill this 4kb page
> with pseudorandom numbers derived from that entropy.  And a side of
> fries..."  This would let callers that don't need actual entropy pass
> a zero (and get solely prng results), while those generating long-term
> keys should ask for as much entropy as their application requires.

This is a design question of how much should be done in userspace,
versus what should be done in the kernel.  One could argue that a DRBG
should be done 100% in userspace, and there is no need to implement
one in the kernel at all.  While I see the argument for why it might
be better to do it in the kernel (userspace applications will screw up
handling what happens across process or thread forks) --- I'm not
convinced the balance of arguments is in favor of adding that level of
creaping featurism, since 99.9% of the applications out there simply
only need a DRBG, and aren't interested (or are competent to specify,
in the case of the application programmers) how many bits of entropy
they need when they are filling a 4kb page --- which isn't a common
use case anyway.

> And perhaps, if an "entropy" parameter is created, we will get a much
> clearer definition about when to set it to what values?  Even from
> John Denker there seems to be a lot of handwaving about entropy versus
> randomness.  When generating a 2275-bit RSA key for long term PGP use,
> shouldn't I ask for 2275 bits of entropy?  Why or why not?  What about
> when generating an ephemeral Diffie-Hellman key for forward secrecy on
> an https access that will likely be closed in seconds?  Or when
> generating an ephemeral Diffie-Hellman key for the IPSEC VPN that will
> protect my traffic over the next week?  And how will the software know
> the duration of time that the key will be used for, anyway; currently
> the code doing key-creation has little to no idea.  Give us some real
> examples and real reasons for the choices suggested.

Programmers tend to assume that all problems can be solved by giving
the user more knobs to twiddle.  But I think there is a real danger in
terms of the paradox of choice, combined with the "would *you* trust
the average application programmer to make intelligent decisions
vis-a-vis cryptographic security"?

> Also, do we want the kernel to mark pages that it puts entropy into as
> "non-swappable" or "erase upon freeing", to keep the kernel from
> making or retaining copies of the page that could be exploited by
> adversaries?  If we're defining a new system interface, are there more
> crypto/security/randomness issues we can address with it?

I see this as a completely orthogonal system interface.  We could
arguement about adding a new madvise(2) flag that might have these
semantics, but it's quite separate from random number generation.  It
also has its own pitfalls; what happens if the user tries to mark all
pages in this fashion.  Since the functionality is a superset of
mlock(2)/mlockall(2), this can be quite problematic from a denial of
service perspective.

Cheers,

						- Ted