[Cryptography] OpenSSL CSPRNG work

Florian Weimer fw at deneb.enyo.de
Wed Jul 5 17:18:26 EDT 2017


* Theodore Ts'o:

> On Sun, Jul 02, 2017 at 10:36:57AM +0200, Florian Weimer wrote:
>> 
>> For glibc, we are also considering adding an implementation of
>> arc4random to an upcoming release.  The consensus view is that we
>> cannot use /dev/urandom because it may not be available in chroots.
>> We support kernels older than 3.17/3.18, so we cannot assume the
>> presence of the getrandom system call.  And getrandom cannot obtain
>> randomness if the kernel pool is not initialized (d'oh).
>
> If the kernel pool is not initialized, what hope does glibc have of
> getting good seed entropy for its CRNG?  What will you plan to do in
> that case?  Please don't say, "oh, we'll just seed from the time and
> process id."  :-)

I already wrote that we're going to use AT_RANDOM (and reseed using
getrandom once it returns data with GRND_NONBLOCK).  If that AT_RANDOM
value is not random, it's up to you guys to fix that.

So use CPU instructions, firmware-provided randomness, hypervisor
interfaces, or cross-core scheduling jitter, whatever works to scrape
together a few hard-to-predict bits.  You are in a much better
position to do that than userland.  We won't implement something like
egd just for use during early boot in userland, and we couldn't access
protected UEFI variables anyway.

> The only thing you can do is what getrandom(2) does, which is block.

That's a non-starter because it would halt the boot process.  In the
futrue, we will need something like arc4random during process
initialization.  And if we block there, the system will never proceed
to the point where it generates more entropy.

> Or if /dev/tty is missing?  And similarly, what does "support" for
> kernels older than 3.17/3.18 mean from a security perspective when
> those kernels are probably filled with security holes?

There are many kernels out there which receive security backports.
Many of them will receive getrandom soon, but certainly not all of
them.  I have no problem with *recommending* kernels with getrandom
support.  We just can't require it.

And the availability of getrandom doesn't solve the early boot issue
anyway.


More information about the cryptography mailing list