Ten years back I had an embedded app that was struggling with this. It's always been my assumption/fear that jitter on an RTOS is not a particularly rich source of entropy. Not to the degree of a Linux kernel sitting on a loud network (maybe switches have worsened this as well?)
Thankfully the system had a few things going for it. First, the flavor of PRNG we were using had a seed function that was cumulative (not all are). Second, useful implementation of system time in nanoseconds (at the time, not a given). And third, the writers had a longish list of bootstrapping tasks to perform prior to making any network calls.
The code that started these tasks was all located in one bootstrapping file. So in addition to whatever crap entropy the libraries could gin up, we pushed another handful of bits of entropy in for each task by taking the nanoseconds and stuffing it into the seed data. doTask1(), seed(nanos()), doTask2(), etc.
This is the same observation made in Linux's RNG, and that is demonstrated in the algorithm for randomness from a biased coin: A high quality mixing algorithm and a large volume biased data can be transformed into a smaller quantity of high quality entropy. Which makes me wonder why Linux doesn't use RDRAND with a low entropy estimate to augment the early sources.
How is that supposed to work? Entropy does not get exhausted.
You can see this when reading /dev/random on a low-entropy machine (such as a VM), and adding whatever you want to the entropy pool manually. The reading process will unblock, read a few bytes, then block again until you add more.
What were you using that uses /dev/random?
I'm not the same guy, so I have no idea what he was reading /dev/random for. Just pointing out that it can in fact be "exhausted."
I'm not a crypto expert either, but wouldn't it still make sense to use /dev/random when generating long-lived keys (e.g. PGP, SSL CA, ssh keys...)?
I understand, I think, that a CSPRNG seeded with just the minimum amount of entropy should be "good enough." More entropy has to be at least theoretically better though, doesn't it?
If the only tradeoff is having to wait a few more seconds or possibly minutes to generate a key I'm going to use for years... why wouldn't I want to do that?
No. https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
Since then there is get_random(2) which does the right thing for most applications.
The man page also has this to say:
> The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted.
I must admit though, that I still don't understand why blocking on insufficient entropy is a bad thing for generating long-lived keys. I'm going to use the key for years, why wouldn't I just wait a couple of seconds or minutes?
In the Linux kernel view of the world, /dev/random "loses" 1 bit of entropy for every bit that gets read.
That is not how cryptographic and hashing primitives work, if it were it would be dangerous to use an AES key to encrypt more than a few megabytes for example.
You wouldn't blame them for it 20-25 years ago, but we've known better for at least 15 years so it'd be nice if they'd get with the program. And it can be fixed without breaking their userspace ABI that they're usually fanatical about not breaking. Linus wanting to break getrandom's ABI just shows he still doesn't understand how CSPRNGs work.
I think the sentiment (or at least my sentiment) is that the number of systems where early entropy is used for something important like key generation but that lack strong sources is diminishing. Many, if no most, x86 and ARM embedded platforms over the past ~5 years have had at at least an on-chip RNG, and over the past 5-10 years some at least some on-board RNG (e.g. Intel NIC controllers often contain an RNG, AMDs PSP provides an RNG, plus various other options like SPI RNG chips).
Ideally there would be multiple sources, but ultimately it's the designer's choice. Likewise, any new platform that lacks any source but has software that expects strong entropy is unequivocally broken. Older systems are disappearing and are unlikely to be upgraded, anyhow.
Excessive paranoia about RDRAND is counter productive. It's speculation that it's weak, while we know for a fact that the machinations userland code goes through to work around the poor semantics and unreliability of Linux kernel randomness interfaces has caused and is causing real problems, including real security problems. At some point the risk of a bugged RDRAND is less than the risk of assuming a non-bugged RDRAND. Plus, if the kernel is loud about its expectations for quality hardware sources it creates an environment where people (embedded designers, savvy laptop purchasers) demand quality sources and manufacturers will compete along that axis (more so than they already do--the VIA C3 was the first to add an on-chip RNG on a mass production chip nearly 15 years ago).