4 ms·

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-mo

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.

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.