[Cryptography] RFC possible changes for Linux random device

John Gilmore gnu at toad.com
Tue Sep 16 17:34:14 EDT 2014


> When a process tries to open /dev/urandom or tries to use the new
> getrandom(2) system call for the first time, if the AES cipher is
> enabled, grab a key and use it set up crypt_tfm structure which would
> be hanging off the Linux's current (task_struct) struxture, using the
> ctr(aes) cipher.

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?

> On a process, exit, exec, or fork, crypto_free_blkcipher(current->tfm)
> gets called to zap the crypto context.

When the file descriptor is closed, the context gets deleted.  (And securely
overwritten?  With zeroes?  With random numbers :-)?

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.

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.

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.

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?

	John




More information about the cryptography mailing list