[PATCH] getrandom: new applet

[Rob Landley]

On 07/10/2016 01:07 PM, Denys Vlasenko wrote:
> Yes, blocking for 3 minutes rather than 6 minutes is an improvement,
> but would 3 minute pause on boot be acceptable for many? I suspect
> it's still bad; and if I would have that system at hand, I'd experiment
> with making it initialize random pool faster. Basically,
> I'd look into kernel source, find what makes it feed entropy pool,
> and do that activity a lot in a separate process, while dd is blocked.

Unfortunately, you can't just order up more entropy on demand unless you
have some variant of a hardware random number generator.

Most opportunitites to collect entropy come in spontaneously from the
outside world, generally when an interrupt provides high precision
timing information that isn't visible (or predictable) to the outside
world: the low bits of that data go into the entropy pool. Keyboard
interrupts, mouse interrupts, and hard drive interrupts are traditional
randomness sources you can collect timing info from, which the rest of
the world can't see. Network packets are NOT generally used for this
because somebody could be listening to your data on the wire and thus
know exactly when your packets arrive, and reverse engineer those inputs
to your entropy pool. (They don't have to get it exact, just close
enough that they can brute force try all the possible inputs to guess
what your software did with those inputs and thus what keys you generated.)

Alas, things like linksys routers haven't got any of those sources, all
they've got are network packets and ONE tiny internal source which is
clock skew between your CPU clock and your PIT, which aren't working
from the same crystal and those crystals heat up independently so they
can vary by a few nanoseconds here and there, so you can check the CPU
cycle counter when the PIT goes off and the clock skew might give you a
bit or two of actual unpredictability. Maybe. (Of course if you've
configured your kernel for a tickless system and it's idle, even THAT
mostly goes away too. Hence the 3 minute wait for this stuff to trickle
collect 128+ bits.)

Anyway, the point is you can't voluntarily collect _more_ entropy from
these sources. They run when there's data to gather, calling the
routines when there isn't new data to gather doesn't help much.

That said, an API that cares about the difference between waiting for
clock skew trickle collection to initialize /dev/urandom's seed and to
wait for the first byte from /dev/urandom seems like it's solving the
wrong problem. If your entropy pool is that starved and you're not
preserving entropy across reboots, something is wrong.

(I haven't focused on what the kernel then does with the entropy it
collects, because they tend to rewrite that stuff every 5 years or so. I
know it doesn't pass it back raw, it feeds it through hash functions.
They also tend to collect more data than they credit to the pool,
because feeding more data into sha1 and so on isn't going to make it
MORE predictable. If they collect 6 bits of data but only add 1 bit of
randomness to the accounting (which controls when /dev/random blocks)
it's because they think some of those bits MIGHT be predictable under
certain circumstances. And those decisions are on the "cryptographer"
side of the line, not the programmer side, so I leave them to it.)

Rob

P.S. A hardware random number generator (which is bubbling random
microscopic electrical interference up into the macro world) or a sound
card with nothing plugged into the input (so you can turn the microphone
jack on and listen to something like "tape hiss") renders the whole
issue moot. Those devices you CAN just request more entropy at will,
that's what they're for. A lot of VMs have a fake paravirtual hardware
random number generators to grab entropy from the host's /dev/random to
feed the entropy-starved client OS's from the less entropy-starved host.
But if you've got that (and trust it), you probably don't have to worry
about /dev/random blocking at all. Nobody ever seems willing to pay to
put one in a cheap plastic router or set-top box...