8 ms·

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 o

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.

spicybright 5y ago
You can easily seed randomness with the user input, like the mouse. https://security.stackexchange.com/questions/10438/what-are-you-doing-when-you-move-your-mouse-randomly-during-a-truecrypt-volume-c https://security.stackexchange.com/questions/10438/what-are-...
- NickNameNick 5y ago
  What mouse? You haven't finished booting yet. You don't know if you're a laptop, a router or a lightbulb.
  - staticassertion 5y ago
    boot the mouse first, then the os
  - spicybright 5y ago
    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.
- detaro 5y ago
  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.
- throw0101a 5y ago
  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?
  - tedunangst 5y ago
    Something something perfect good blah blah.
  - NobodyNada 5y ago
    > 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. [0]: https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4
- RL_Quine 5y ago
  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".
- cerved 5y ago
  great windows solution
- spicybright 5y ago
  I am wrong, please ignore my above post.
a-dub 5y ago
you could try rowhammering yourself maybe? aren't the bitflips both spatially and temporally random, depending on em conditions? i never knew that any user could write into the entropy sources by writing to the random block devices... that's sketch.
- kardos 5y ago
  If your hardware is impervious to rowhammer you'd get nothing
- RL_Quine 5y ago
  Why is that sketchy? There’s nothing you could write that would make the output of the RNG worse.
  - a-dub 5y ago
    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.
    - RL_Quine 5y ago
      Is it secret? You can just cat file.txt > /dev/random if you want to seed the generator.
      - a-dub 5y ago
        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...

spicybright 5y ago

You can easily seed randomness with the user input, like the mouse. https://security.stackexchange.com/questions/10438/what-are-you-doing-when-you-move-your-mouse-randomly-during-a-truecrypt-volume-c https://security.stackexchange.com/questions/10438/what-are-...

NickNameNick 5y ago
What mouse? You haven't finished booting yet. You don't know if you're a laptop, a router or a lightbulb.
- staticassertion 5y ago
  boot the mouse first, then the os
- spicybright 5y ago
  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.
detaro 5y ago
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.
throw0101a 5y ago
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?
- tedunangst 5y ago
  Something something perfect good blah blah.
- NobodyNada 5y ago
  > 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. [0]: https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4
RL_Quine 5y ago
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".
cerved 5y ago
great windows solution
spicybright 5y ago
I am wrong, please ignore my above post.

a-dub 5y ago

you could try rowhammering yourself maybe? aren't the bitflips both spatially and temporally random, depending on em conditions? i never knew that any user could write into the entropy sources by writing to the random block devices... that's sketch.

kardos 5y ago
If your hardware is impervious to rowhammer you'd get nothing
RL_Quine 5y ago
Why is that sketchy? There’s nothing you could write that would make the output of the RNG worse.
- a-dub 5y ago
  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.
  - RL_Quine 5y ago
    Is it secret? You can just cat file.txt > /dev/random if you want to seed the generator.
    - a-dub 5y ago
      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...