I realize part of the issue here is kickstarting the process right after boot. But is that the entire issue?
https://security.stackexchange.com/questions/10438/what-are-...
If the question is can you generate random numbers on a computer in a sealed room with absolutely no input, a static image loaded on it, and you have no storage devices to keep any sate, of course you can't generate a random number.
The vast majority of things we put computers in do have some form of input that is random enough for a seed unless you design it that way on purpose.
Yet we can't find enough entropy in 2022 to boot a system?
Also, why don't the BSDs seem to have as many problems on the subject as Linux apparently does?
> Yet we can't find enough entropy in 2022 to boot a system?
A Linux system will have no trouble at all if you're around to mash the keyboard while it boots. Nor if it's doing normal computer things like (IIRC) running processes on the CPU, talking over the network, or accessing files, all of which create more than enough activity & jitter to seed the entropy pool within a few seconds. Or if your computer has some form of writable storage, in which case the kernel loads some high-quality entropy that was saved from the previous boot.
The issue in question is a quite rare edge case. It only affects certain kinds of embedded systems that lack hardware capable of generating entropy on-demand, don't have writable storage, and run software that (for whatever reason) absolutely needs random numbers early during the boot process. In this situation, it is possible to get into a deadlock where a process is waiting for entropy to be available, but the system cannot reach a state where it is capable of generating entropy until that process completes.
Linux currently provides /dev/urandom to work around the issue by providing insecure randomness instead of blocking if insufficient entropy is available. This is rarely a good solution, and it can obviously lead to unexpected security vulnerabilities. Making the issue worse is the fact that /dev/random used to have much more annoying problems, so a lot of old code uses /dev/urandom when it definitely should be using /dev/random in this day and age.
The kernel developers tried to solve the problem once and for all by adding a "jitter dance" that can generate entropy out of thin air, and making /dev/urandom the same thing as /dev/random. Bu, unsurprisingly, this broke buggy cod on platforms that can't do the jitter dance.
> Also, why don't the BSDs seem to have as many problems on the subject as Linux apparently does?
A bit of googling shows they have exactly the same problems. The FreeBSD manpage for /dev/random [0] says that /dev/random and /dev/urandom behave identically on BSDs, with a setting allowing the system administrator to choose whether they block or return insecure randonmess in that edge-case situation.
The reason you've seen so much news about the problem on Linux is because the Linux kernel devs recognize that the current situation is very non-ideal, and they really want to find a way to fix it without breaking compatibility with buggy software running in niche environments. I don't know why you don't see as much news about the BSDs, but it must be either because BSD is less popular than Linux, or maybe BSD developers haven't put as much effort into fixing the problem. In any case, I see these discussions as reassuring: it demonstrates that Linux kernel developers care about fixing issues that only affect a tiny minority of users, and that they care about maintaining near-perfect backwards compatibility, even with ancient, buggy, and niche software.
[0]: https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4
I think that's certainly a significant portion of it, but also, the BSD behavior has been fairly consistent for a long time, while the Linux behavior has been changing recently. It's a bigger deal if your embedded system (or virtual machine) breaks when you upgrade to a newer kernel than if it's always been broken.
> Entropy data stored previously is provided to the kernel during the boot sequence and used as inner-state of a stream cipher. High quality data is available immediately upon kernel startup.
> For portability reasons, never use /dev/random. On OpenBSD, it is an alias for /dev/urandom, but on many other systems misbehaves by blocking because their random number generators lack a robust boot-time initialization sequence.
> For portability reasons, never use /dev/random. On OpenBSD, it is an alias for /dev/urandom, but on many other systems misbehaves by blocking
This seems like bad advice to me (at least as a blanket statement). On recent versions of Linux, /dev/random only blocks if the kernel cannot guarantee cryptographically secure randomness. If you use /dev/urandom in this situation, you get potentially insecure randomness, which can lead to security vulnerabilities. My understanding of the current best practice is: unless you're running on weird embedded hardware, writing an application which absolutely needs randomness during earlyboot, AND you don't care about the quality of the randomness, you shouldn't use urandom.
Perhaps the manpage was referencing an older version of Linux where the entropy pool could be "drained" and had to be re-seeded periodically, but that was not a great design and was replaced in 2020: https://lwn.net/Articles/808575/
It's also my understanding that /dev/urandom on openbsd will never block for a user process, nor anything that I've ever needed to worry about in the kernel.
Some additional info that I found: https://www.openbsd.org/papers/hackfest2014-arc4random/
i never knew that any user could write into the entropy sources by writing to the random block devices... that's sketch.
but that's less interesting than generating entropy by exploiting the digital systems equivalent of quantum effects. which has me wondering now: what if quantum entanglement is just rowhammer for reality...
does this mean that users who don't feed the pool manually have inferior keys?
it's an interesting question: is there a clever way to extract random bits from a clocked ttl system by driving it in some weird way that is platform independent enough to cover the bases that don't already have hardware support for generating random bits (or have cycle counters)?
i suppose the problem is that not all chips have a cycle counter so extracting clock drift/jitter isn't always feasible... i wonder what else could work...
race conditions could be an interesting way to try to draw random bits, but probably very hardware dependent... i wonder if there are other glitchy things...
The clue is in randomness seed files. You won't have one of these on a PC because you don't need it. Once you have your 128/256 bits of entropy you can stretch this using a DRBG for actual use and it'll be good.
The problem is systems that are much more deterministic, because they have simpler CPUs that don't do speculative execution, or have anything fancy by way of caching. Their peripherals are fixed at boot time via a devicetree file and udev style peripheral plug and play doesn't happen.
These tend to be embedded use cases. To get around this, you have a seed file to give you at least some good entropy. Then you mix in the best you can get and update that seed file for next boot. Hopefully this plus what you get while the device is on is enough for next time.
A lot of crypto including the tls you might use to get stuff off the internet will break if the quality of randomness is not good enough.
You are reading 'Linux' and hearing 'desktop' but the reality is there is a lot more embedded Linux than desktop Linux, and that's where the entropy problems start to creep in depending on the device in question.
Yeah, this is a weird example of availability bias. Of the literally billions of Linux instances on the planet, how many are desktops these days? One in a thousand? Even less? Most of them are Android phones, most of the rest (other) embedded devices, almost all of the rest, servers.
A bit more info: https://security.stackexchange.com/questions/157684/why-does...
I don't think that would help here.
Really it's during the bootstrap phase, unless you define that process as complete once the CPU has branched into the kernel's address space, which I wouldn't consider a useful definition. After all, kernel's enumeration of the attached devices and such is also part of the bootstrap process.
(The issues associated with seeding an RNG with data entirely controlled by a third party are left as an exercise for the reader)
I suppose this situation works if you assume both a trusted third party service and a trusted networking layer, but all those assumptions greatly inhibit usefulness.