Admittedly, this would assume the computer is connected to the Internet, but is there not some theoretically reasonable way to get entropy off the Internet? Maybe some server with a known certificate that can return entropy from lava lamps or similar?
I realize part of the issue here is kickstarting the process right after boot. But is that the entire issue?
You're awoken abruptly, you've just got out of grub, you don't have networking interfaces, you don't have any higher level cryptography libraries, the concept of connecting to something on the internet to get entropy in order to continue booting seems like a complete fantasy. You can gather what little entropy you have, mix it with suspicious sources like RDRAND, and paper over the cracks once you've got some better sources on the burner.
I think that rowhammering is too hardware specific. I could imagine much slower embedded devices being immune because their old slow RAM is too robust, and it would really suck if ECC RAM (perhaps even opaquely ECC RAM) causes your boot to hang.
maybe you could do something with race conditions?
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...
well, i'm not a random number scientist or anything... but i do find it a little troubling that the random number generator at the core of linux that is trusted by everything has a secret "add more random" button on it.
can you? anyone in the village is allowed to dump old junk in there. old shoes, dead cats, kernel command lines, politician emails, old diaries and missing tax returns. and then what happens once it's in there? well, it can't really be trusted or used to actually seed the rng. half the junk in there is static. so it just kinda quietly gets mixed into the entropy hash pools... to what end exactly? it's neither ignored nor actually used in a meaningful way, so the whole problem it's trying to solve is ill-posed. this is a distinct code smell, where the problem was very hard and no good solution was found, so there are still remnants of tried and aborted approaches laying around like pieces of disused viaduct after a major earthquake. for something as critical as this, yes, i'd argue that it is indeed, sketchy.
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...
Ok then. Laptops have temperature sensors that can add entropy. A super small embeded device like a lightbulb should keep one of it's I/O pins open. A floating wire also gives entropy.
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.
Somehow I managed to generated RSA keys with PGP 2.x in the early 1990s on a Linux system without a mouse or an always-on connection to the Internet. It took about five minutes while I mashed the keyboard during that time, but I was able to do it.
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?
> It took about five minutes while I mashed the keyboard
> 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.
> 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.
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.
The scheme described there has the disadvantage of requiring a writable filesystem, whereas Linux is designed to run on embedded hardware with no writable storage. If you're running "normal" hardware, Linux can do the same "save some entropy in a file" trick.
> 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 my understanding that openbsd boot will take a bit longer to seed the random seed file when there is not a prior seed file on a writable filesystem, just like during the first boot after the os install. This was my experience when I created an openbsd router that booted from a single file and had no persistent storage.
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.
Most Linux systems don't even have a mouse, and even those that do, users tend not to fiddle with them in early boot, so no signal there, even if you've gotten around to initializing it already.
The majority of LInux devices do not have any keyboard or mouse, and those that do will see absolutely no input during init, you've never seen "move the mouse around a bunch to begin boot".
No it isn't the entire issue. Or more precisely on your average desktop system this isn't really a problem. The jitter dance will suffice here.
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.
> You are reading 'Linux' and hearing 'desktop' but the reality is there is a lot more embedded Linux than desktop Linux
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.
If you ask me, every motherboard should ship with a bit of Americium 241, that way they have a physical entropy source AND can detect when a fire has occurred inside the case (:
Apart from all the other reasons this is a very bad idea, the brick wall you run into is that you need cryptographically secure randomness to safely fetch randomness from the Internet.
> I realize part of the issue here is kickstarting the process right after boot.
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.
Even assuming trust of the 3p service - establishing an ssl connection actually requires entropy too. Even more raw - how could a zero entropy client generate a nonce to protect itself against replay attacks by man in the middle?
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.
I realize part of the issue here is kickstarting the process right after boot. But is that the entire issue?