9 ms·

New and improved Linux Random Number Generator ready for testing

100 points by feross 5y ago

DevX101 5y ago
> According to Müller, LPRG incorporates four entropy sources that operate completely independent of each other including execution timing jitter and the timing of the arrival of interrupts. Can you 'lie' to the operating system about these sources of entropy in order to control the random number generation?
- not-elite 5y ago
  Of course. https://groups.google.com/g/randomness-generation/c/eNnepJ_65eQ https://groups.google.com/g/randomness-generation/c/eNnepJ_6...
- CodeArtisan 5y ago
  Last time i checked, /dev/random was receiving entropy from * The kernel command line string at boot. * Every time there is an input event (mouse, keyboard, ...). * Every time there is a disk event. * By retrieving the cpu cycles counter (RDTSC on x86) from random interrupts. * Hardware RNGs(RDRAND on x86). * From latent entropy every time a process is created. Latent entropy is a 64 bits unsigned that has its state modified every time a procedure with the attribute latent_entropy is executed. The latent_entropy attribute is implemented by a GCC plugin and adds random operations on the latent_entropy seed to a procedure. For example void foo(bool a) __attribute__((latent_entropy)) { if (a) bar(); else baz(); } become void foo(bool a) __attribute__((latent_entropy)) { if (a) { latent_entropy OP NUMBER; bar(); } else { latent_entropy OP NUMBER; baz(); } } where OP (*= += -= ^= ...) and NUMBER are randomly generated at compilation time. Many kernel procedures handling interrupts have the latent_entropy attribute. more information at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/scripts/gcc-plugins/latent_entropy_plugin.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
charcircuit 5y ago
>The /dev/random is the “very foundation” of cryptography on Linux, developer Stephan Müller told The Daily Swig. “If /dev/random breaks, the entire cryptography on Linux is broken,” Müller said. I thought using /dev/random was depricated and that you should instead use a getrandom syscall that blocks if you don't have enough entropy.
- kenniskrag 5y ago
  in the the man page they say only legacy > 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. It will return random bytes only within the estimated number of bits of fresh noise in the entropy pool, blocking if necessary. /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays. and recommend: > Linux 3.17 and later provides the simpler and safer getrandom(2) interface which requires no special files; see the getrandom(2) manual page for details.
- cperciva 5y ago
  You're right, but when kernel developers talk about /dev/random they generally mean the underlying RNG, not the interface by which you access it. To a userland developer the phrase "read from /dev/random via the getrandom system call" is nonsense but to a kernel developer it sounds reasonable.
- dTal 5y ago
  /dev/random does block "if you don't have enough entropy" (in contrast to /dev/urandom, which doesn't). The only difference is that getrandom() doesn't require a file descriptor to use. Note that "if you don't have enough entropy" is not based on any rigorous formal analysis, which is why /dev/urandom has been recommended for a long time, and why the entire concept of blocking randomness syscalls is controversial in kernel-land: https://lwn.net/Articles/800509/ https://lwn.net/Articles/800509/
- shaicoleman 5y ago
  Since Linux 5.6, /dev/random only blocks during initialization until it gets the initial entropy, and behaves like /dev/urandom afterwards. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Random-Rework https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....
danuker 5y ago
If lives (or life savings) are at stake, I'd still xor some dice values in the mix. https://glacierprotocol.org/docs/deposit/generate-cold-storage-data/ https://glacierprotocol.org/docs/deposit/generate-cold-stora...
- throw0101a 5y ago
  See also Diceware: * https://en.wikipedia.org/wiki/Diceware https://en.wikipedia.org/wiki/Diceware Useful site: * https://www.rempe.us/diceware/ https://www.rempe.us/diceware/
- beermonster 5y ago
  Or some lava lamps
  - kuroguro 5y ago
    Probably a reference to cloudflare: https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/ https://www.cloudflare.com/learning/ssl/lava-lamp-encryption...
    - hoytech 5y ago
      lavarand was invented and patented by SGI in 1996: https://www.lavarand.org/news/lavadiff.html https://www.lavarand.org/news/lavadiff.html
      - genewitch 5y ago
        There was a library to use webcams for entropy called lavarnd up until about 8 years ago, as well. I am unsure if the api to the os changed or there's a functional difference between ccd and cmos or whatever. I do a lot of entropy research, and was annoyed I had to roll my own implementation for a no-photon camera entropy source.
DeathArrow 5y ago
I hope NSA is not involved. https://twitter.com/matthew_d_green/status/1433470109742518273 https://twitter.com/matthew_d_green/status/14334701097425182...
- rurban 5y ago
  Which comes directly from a suspected NSA mouth. No, it's from the German BSI, which is a NSA collaborator. Still better than the current implementation.
  - joconde 5y ago
    Who suspects Matthew Green of being an "NSA mouth", and why? He's constantly advocating for more privacy and stronger crypto in software.
    - zrm 5y ago
      Also, what he's talking about is from the Snowden stuff: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG
iamgopal 5y ago
How to measure randomness ? Even distribution ? Volatility ? Independence ?
- davidgrenier 5y ago
  http://simul.iro.umontreal.ca/testu01/tu01.html http://simul.iro.umontreal.ca/testu01/tu01.html Maybe? I'm not familiar, summarily discussed it with research director.
- kevincox 5y ago
  You can't truly measure randomness, by definition a true random source would have exactly the same probably to produce any sequence of bits, so given any two sequences it is impossible to say for sure that one is "more random" than another. However there are many well-accepted tests for judging that a sequences of bits is likely to be random. Basically these tests are looking for common failure modes and expected statistics that are likely to fail if your source isn't truly random (for example distribution skew, repeating patterns, ...). But it is important to clarify that these tests are guesses. The have both false-positives and false-negatives. For example a "random number generator" that just has a large hardcoded list of random-looking values and loops over the list may pass a test if the list is long enough that the loop can't be detected, even though the values are decidedly not random. On the other hand a true random source may generate a very long sequence of zeros, the probability would be infinitesimal, but it is entirely possible and doesn't mean that the source isn't random.
  - asdf_snar 5y ago
    I have a question about the statement "you can't truly measure randomness", if it's alright (since you seem knowledgeable about this). > For example a "random number generator" that just has a large hardcoded list of random-looking values and loops over the list may pass a test if the list is long enough that the loop can't be detected, even though the values are decidedly not random. My understanding is that's entirely fine from a statistical point of view. One can establish properties of this sequence up to some probabilistic error, perhaps also depending on the total number of values from the list that end up being used. Isn't this in some sense analogous to measurement error? As far as I know, nothing can be precisely "measured" either. Is there a deeper sense in which the quality of the random sequence can't be analogously assessed?
ncmncm 5y ago
We should be stirring in the low bits of image pixels on attached cameras, and the bottom bits of mic and radio receiver input.
- willis936 5y ago
  Only if we trust the camera to not have a specific upper limit on image processing. It's also a decent attack vector. Any old USB plug could lower system entropy. If everything else is done properly this isn't an issue, but it still seems to increase attack surface area for little gain.
  - strenholme 5y ago
    If we use a secure cryptographic algorithm which combines different entropy sources and then hashes them together, even a completely insecure additional source of entropy will not reduce the security of /dev/random [1] If we have 10 different sources of entropy for our random number generator, and only one of them is truly random, our random number generator is still secure. [1] There’s an issue where /dev/random will have less actual entropy than it think it has, but as long as we have 128 bits[2] or more of actual entropy, the output will still be secure. [2] 256 bits if worrying about quantum computers or theoretical future computers the size of a continent
    - IgorPartola 5y ago
      What exactly is the point of adding 9 known insecure sources if only one is doing the actual useful work? Is it less secure? I guess not. Is it more secure? Doesn’t seem like it.
      - BenjiWiebe 5y ago
        If you add 9 known not-very-good sources of randomness, it's still better than adding no sources of randomness. Now if your 9 bad sources are 100% predictable, then yes, there's no point in adding them.
      - 5y ago
pierreprinetti 5y ago
FILIPPOOOOOOOOOOO come and save us
strenholme 5y ago
There is a lot said for making the Linux random number generator configurable. A good entropy (random number) source takes entropy from a number of different sources and combines it with a cryptographic strong algorithm: Either a strong hash whose output is made the key and IV for a stream cipher, or directly using an Extendable-Output Function (XOF) such as a cryptographic sponge. [1] For example, there is some controversy with the RDRAND (the x86 ”give me random bits” op code) operation, with concerns that maybe the numbers weren’t truly random, and at least one known security hole where the RDRAND output could leak under some circumstances. However, it’s widely available and probably makes good random bits. However, if it doesn’t, we want other sources of entropy (microphone output low bits, interrupt timings, etc.) so /dev/random or /dev/urandom still gives us strong entropy even if RDRAND is completely busted. [1] I personally think a cryptographic sponge is ideal for this, since sponge functions have absorb, output, and duplex (absorb after output, i.e. accept new entropy from the system after outputting bits) functionality
- jstanley 5y ago
  When I first got my Ryzen CPU, it had some bug where RDRAND always returned -1! Fortunately this was fixed in a microcode update.
  - 0x0 5y ago
    Experienced something similar here. NodeJS node-sass would crash with "rdrand failed". Super weird experience to have to apply a BIOS update to fix a node_modules build failure, but that's 2021.
- CJefferson 5y ago
  While having it configurable is one option, I'd prefer to just "chuck everything in". A feature I would like (which would make things more complicated I realise) would be to have a variety of sources, which estimated quality for each source, and then check the quality is still high even if one of the sources is "broken".
ape4 5y ago
You never hear about developments of the RNG on other OSes. It gives me more confidence that the Linux RNG is constantly being reviewed.
- masklinn 5y ago
  > You never hear about developments of the RNG on other OSes. Probably because you don't listen? > It gives me more confidence that the Linux RNG is constantly being reviewed. It took decades for the linux devs to abandon their idiotic concept of running out of entropy and making /dev/random stop blocking (that happened last year in the 5.6 kernel). Hell, after getentropy was introduced by openbsd, not only did linux decide to invent their own variant they just had to replicate /dev/random's running-out-of-entropy behaviour.
  - zamadatix 5y ago
    > It took decades for the linux devs to abandon their idiotic concept of running out of entropy and making /dev/random stop blocking (that happened last year in the 5.6 kernel It wasn't an idiotic concept it was 1 part "No longer needed for trust in the algorithms used by /dev/urandom" and 1 part "Did 2 functions but was really used for 1". Since the majority of people were using it just as a source of secure random data (not the 2nd use of aggregating sources of entropy) and CSPRNGs (and the implementation of in the kernel) are much more trusted now it made sense to change. That doesn't mean it was an idiotic concept it just outlived its reasons for having been implemented that way and was changed. For clarity's sake to others that may not be as familiar /dev/random still blocks it was the concept of the blocking pool that was removed. I.e. once it has been fully initialized post boot it will serve an endless stream of random data as fast as it can regardless of how much new entropy enters the system. This is what tools actually need, some other systems have provided this via a separate /dev/arandom. /dev/urandom still acts the same way it always has, it'll serve you the output of the CSPRNG regardless if it has had enough time to properly seed it with entropy yet (so may act more like a standard PRNG very early into the boot cycle).
- loeg 5y ago
  https://aka.ms/win10rng https://aka.ms/win10rng
ploxiln 5y ago
Stephan Müller has proposed his "LRNG" rewrite 5 years ago, and it was not well received by the linux random subsystem maintainer Ted Ts'o: https://lkml.org/lkml/2016/4/21/839 https://lkml.org/lkml/2016/4/21/839 but there has been a notable development in the subsystem this year, finally `/dev/random` blocks only before initialization, and never after! https://lore.kernel.org/lkml/20200131204924.GA455123@mit.edu/ https://lore.kernel.org/lkml/20200131204924.GA455123@mit.edu...
salmo 5y ago
This is something that has frustrated me for years. There has been no interest in modernizing the Linux PRNG really ever. This article doesn't go into more depth so I don't know if it's just tacking on more entropy sources and algorithm support or a real modernization. Windows, MacOS, every BSD, Solaris, etc. have moved past the (blocking) /dev/random vs /dev/urandom to more mathematically sound solutions. (Seriously, measuring entropy?) But Torvalds, Ts'o, etc. have blocked, belittled, or ignored any movement there. It's crazy that the OS that runs all the things essentially has a roll-your-own-crypto PRNG at its core rather than relying on actual experts for that. Unfortunately, it's "good enough" to not HAVE to change. Use /dev/random sparingly to seed your own PRNG, change your Java config to use /dev/urandom, or (shudder) use rngd to make it seed itself. At least once a year I hit some COTS product that craps itself under load blocking on /dev/random on a VM, causing an outage. Yes, it's a "worked on my laptop" problem, but an unnecessary rake to leave out in the garden.
- gerdesj 5y ago
  This is from early last year: https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/ "Removing the Linux /dev/random blocking pool"
- jeltz 5y ago
  Linux has also moved past it, but only quite recently. https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/
- ploxiln 5y ago
  Blocking /dev/random has been a problem that many people were interested about for a long time, and it has had alternatives: /dev/urandom since forever (though it has a big problem for some short period just after bootup), getentropy() since 2015 can do the right thing with the right options, and finally since 2020 /dev/random does the right thing - it only blocks until seeded, then gives unlimited secure random bytes. (I only learned about this 2020 update in this very thread!) My understanding is that /dev/random behavior persisted for so long only due to some dumb corporate/military compliance thing that some huge companies "needed". EDIT: apparently this was due to NIST standard SP800-90B and maybe German AIS 31, and the most recent idea is to forget them, and have orgs that really need the strange/problematic blocking behavior implement it in user-space.
jdlyga 5y ago
tl;dr the solution is a USB-powered cup of Yahtzee dice. There was some debate over the color of the dice and usb-c vs usb-a. But it will be included in the next kernel release and shipped out to every user of the linux kernel with the next update.
jeffbee 5y ago
QQ: why does this belong in the kernel at all?
- JoachimS 5y ago
  Two reasons. (1) The kernel itself needs access to good random numbers for its operation. (2) Having a source of random number is something many applications need, and just like other services (storage, communication) random numbers a good thing to provide. As the article shows, generating good random numbers generated based on physical entropy is a complex process. Not providing this as a service to applications would probably lead to many applications having bad random numbers. Just like we don't expect all applications to implement their own version of TCP. Note that applications may use PRNGs from a library, for example Clib. But unless you want just pseudo randomness you somehow need to get entropy/noise from the physical machine. And the service presented to the application (for example via /dev/random) provides that.
  - JoachimS 5y ago
    Though of course, this could be in a userland library too. Just reading entropy from HW (exposed by the kernel). But the kernel still needs access to random number it can control and trust.
daneel_w 5y ago
I wonder why they just didn't take a cue from OpenBSD's arc4random solution years ago, instead of this drawn-out contortion.

100 points by feross 5y ago

> According to Müller, LPRG incorporates four entropy sources that operate completely independent of each other including execution timing jitter and the timing of the arrival of interrupts. Can you 'lie' to the operating system about these sources of entropy in order to control the random number generation?

not-elite 5y ago
Of course. https://groups.google.com/g/randomness-generation/c/eNnepJ_65eQ https://groups.google.com/g/randomness-generation/c/eNnepJ_6...
CodeArtisan 5y ago
Last time i checked, /dev/random was receiving entropy from * The kernel command line string at boot. * Every time there is an input event (mouse, keyboard, ...). * Every time there is a disk event. * By retrieving the cpu cycles counter (RDTSC on x86) from random interrupts. * Hardware RNGs(RDRAND on x86). * From latent entropy every time a process is created. Latent entropy is a 64 bits unsigned that has its state modified every time a procedure with the attribute latent_entropy is executed. The latent_entropy attribute is implemented by a GCC plugin and adds random operations on the latent_entropy seed to a procedure. For example void foo(bool a) __attribute__((latent_entropy)) { if (a) bar(); else baz(); } become void foo(bool a) __attribute__((latent_entropy)) { if (a) { latent_entropy OP NUMBER; bar(); } else { latent_entropy OP NUMBER; baz(); } } where OP (*= += -= ^= ...) and NUMBER are randomly generated at compilation time. Many kernel procedures handling interrupts have the latent_entropy attribute. more information at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/scripts/gcc-plugins/latent_entropy_plugin.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

charcircuit 5y ago

>The /dev/random is the “very foundation” of cryptography on Linux, developer Stephan Müller told The Daily Swig. “If /dev/random breaks, the entire cryptography on Linux is broken,” Müller said. I thought using /dev/random was depricated and that you should instead use a getrandom syscall that blocks if you don't have enough entropy.

kenniskrag 5y ago
in the the man page they say only legacy > 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. It will return random bytes only within the estimated number of bits of fresh noise in the entropy pool, blocking if necessary. /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays. and recommend: > Linux 3.17 and later provides the simpler and safer getrandom(2) interface which requires no special files; see the getrandom(2) manual page for details.
cperciva 5y ago
You're right, but when kernel developers talk about /dev/random they generally mean the underlying RNG, not the interface by which you access it. To a userland developer the phrase "read from /dev/random via the getrandom system call" is nonsense but to a kernel developer it sounds reasonable.
dTal 5y ago
/dev/random does block "if you don't have enough entropy" (in contrast to /dev/urandom, which doesn't). The only difference is that getrandom() doesn't require a file descriptor to use. Note that "if you don't have enough entropy" is not based on any rigorous formal analysis, which is why /dev/urandom has been recommended for a long time, and why the entire concept of blocking randomness syscalls is controversial in kernel-land: https://lwn.net/Articles/800509/ https://lwn.net/Articles/800509/
shaicoleman 5y ago
Since Linux 5.6, /dev/random only blocks during initialization until it gets the initial entropy, and behaves like /dev/urandom afterwards. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Random-Rework https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

danuker 5y ago

If lives (or life savings) are at stake, I'd still xor some dice values in the mix. https://glacierprotocol.org/docs/deposit/generate-cold-storage-data/ https://glacierprotocol.org/docs/deposit/generate-cold-stora...

throw0101a 5y ago
See also Diceware: * https://en.wikipedia.org/wiki/Diceware https://en.wikipedia.org/wiki/Diceware Useful site: * https://www.rempe.us/diceware/ https://www.rempe.us/diceware/
beermonster 5y ago
Or some lava lamps
- kuroguro 5y ago
  Probably a reference to cloudflare: https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/ https://www.cloudflare.com/learning/ssl/lava-lamp-encryption...
  - hoytech 5y ago
    lavarand was invented and patented by SGI in 1996: https://www.lavarand.org/news/lavadiff.html https://www.lavarand.org/news/lavadiff.html
    - genewitch 5y ago
      There was a library to use webcams for entropy called lavarnd up until about 8 years ago, as well. I am unsure if the api to the os changed or there's a functional difference between ccd and cmos or whatever. I do a lot of entropy research, and was annoyed I had to roll my own implementation for a no-photon camera entropy source.

DeathArrow 5y ago

I hope NSA is not involved. https://twitter.com/matthew_d_green/status/1433470109742518273 https://twitter.com/matthew_d_green/status/14334701097425182...

rurban 5y ago
Which comes directly from a suspected NSA mouth. No, it's from the German BSI, which is a NSA collaborator. Still better than the current implementation.
- joconde 5y ago
  Who suspects Matthew Green of being an "NSA mouth", and why? He's constantly advocating for more privacy and stronger crypto in software.
  - zrm 5y ago
    Also, what he's talking about is from the Snowden stuff: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG

iamgopal 5y ago

How to measure randomness ? Even distribution ? Volatility ? Independence ?

davidgrenier 5y ago
http://simul.iro.umontreal.ca/testu01/tu01.html http://simul.iro.umontreal.ca/testu01/tu01.html Maybe? I'm not familiar, summarily discussed it with research director.
kevincox 5y ago
You can't truly measure randomness, by definition a true random source would have exactly the same probably to produce any sequence of bits, so given any two sequences it is impossible to say for sure that one is "more random" than another. However there are many well-accepted tests for judging that a sequences of bits is likely to be random. Basically these tests are looking for common failure modes and expected statistics that are likely to fail if your source isn't truly random (for example distribution skew, repeating patterns, ...). But it is important to clarify that these tests are guesses. The have both false-positives and false-negatives. For example a "random number generator" that just has a large hardcoded list of random-looking values and loops over the list may pass a test if the list is long enough that the loop can't be detected, even though the values are decidedly not random. On the other hand a true random source may generate a very long sequence of zeros, the probability would be infinitesimal, but it is entirely possible and doesn't mean that the source isn't random.
- asdf_snar 5y ago
  I have a question about the statement "you can't truly measure randomness", if it's alright (since you seem knowledgeable about this). > For example a "random number generator" that just has a large hardcoded list of random-looking values and loops over the list may pass a test if the list is long enough that the loop can't be detected, even though the values are decidedly not random. My understanding is that's entirely fine from a statistical point of view. One can establish properties of this sequence up to some probabilistic error, perhaps also depending on the total number of values from the list that end up being used. Isn't this in some sense analogous to measurement error? As far as I know, nothing can be precisely "measured" either. Is there a deeper sense in which the quality of the random sequence can't be analogously assessed?

ncmncm 5y ago

We should be stirring in the low bits of image pixels on attached cameras, and the bottom bits of mic and radio receiver input.

willis936 5y ago
Only if we trust the camera to not have a specific upper limit on image processing. It's also a decent attack vector. Any old USB plug could lower system entropy. If everything else is done properly this isn't an issue, but it still seems to increase attack surface area for little gain.
- strenholme 5y ago
  If we use a secure cryptographic algorithm which combines different entropy sources and then hashes them together, even a completely insecure additional source of entropy will not reduce the security of /dev/random [1] If we have 10 different sources of entropy for our random number generator, and only one of them is truly random, our random number generator is still secure. [1] There’s an issue where /dev/random will have less actual entropy than it think it has, but as long as we have 128 bits[2] or more of actual entropy, the output will still be secure. [2] 256 bits if worrying about quantum computers or theoretical future computers the size of a continent
  - IgorPartola 5y ago
    What exactly is the point of adding 9 known insecure sources if only one is doing the actual useful work? Is it less secure? I guess not. Is it more secure? Doesn’t seem like it.
    - BenjiWiebe 5y ago
      If you add 9 known not-very-good sources of randomness, it's still better than adding no sources of randomness. Now if your 9 bad sources are 100% predictable, then yes, there's no point in adding them.
    - 5y ago

pierreprinetti 5y ago

FILIPPOOOOOOOOOOO come and save us

strenholme 5y ago

There is a lot said for making the Linux random number generator configurable. A good entropy (random number) source takes entropy from a number of different sources and combines it with a cryptographic strong algorithm: Either a strong hash whose output is made the key and IV for a stream cipher, or directly using an Extendable-Output Function (XOF) such as a cryptographic sponge. [1] For example, there is some controversy with the RDRAND (the x86 ”give me random bits” op code) operation, with concerns that maybe the numbers weren’t truly random, and at least one known security hole where the RDRAND output could leak under some circumstances. However, it’s widely available and probably makes good random bits. However, if it doesn’t, we want other sources of entropy (microphone output low bits, interrupt timings, etc.) so /dev/random or /dev/urandom still gives us strong entropy even if RDRAND is completely busted. [1] I personally think a cryptographic sponge is ideal for this, since sponge functions have absorb, output, and duplex (absorb after output, i.e. accept new entropy from the system after outputting bits) functionality

jstanley 5y ago
When I first got my Ryzen CPU, it had some bug where RDRAND always returned -1! Fortunately this was fixed in a microcode update.
- 0x0 5y ago
  Experienced something similar here. NodeJS node-sass would crash with "rdrand failed". Super weird experience to have to apply a BIOS update to fix a node_modules build failure, but that's 2021.
CJefferson 5y ago
While having it configurable is one option, I'd prefer to just "chuck everything in". A feature I would like (which would make things more complicated I realise) would be to have a variety of sources, which estimated quality for each source, and then check the quality is still high even if one of the sources is "broken".

ape4 5y ago

You never hear about developments of the RNG on other OSes. It gives me more confidence that the Linux RNG is constantly being reviewed.

masklinn 5y ago
> You never hear about developments of the RNG on other OSes. Probably because you don't listen? > It gives me more confidence that the Linux RNG is constantly being reviewed. It took decades for the linux devs to abandon their idiotic concept of running out of entropy and making /dev/random stop blocking (that happened last year in the 5.6 kernel). Hell, after getentropy was introduced by openbsd, not only did linux decide to invent their own variant they just had to replicate /dev/random's running-out-of-entropy behaviour.
- zamadatix 5y ago
  > It took decades for the linux devs to abandon their idiotic concept of running out of entropy and making /dev/random stop blocking (that happened last year in the 5.6 kernel It wasn't an idiotic concept it was 1 part "No longer needed for trust in the algorithms used by /dev/urandom" and 1 part "Did 2 functions but was really used for 1". Since the majority of people were using it just as a source of secure random data (not the 2nd use of aggregating sources of entropy) and CSPRNGs (and the implementation of in the kernel) are much more trusted now it made sense to change. That doesn't mean it was an idiotic concept it just outlived its reasons for having been implemented that way and was changed. For clarity's sake to others that may not be as familiar /dev/random still blocks it was the concept of the blocking pool that was removed. I.e. once it has been fully initialized post boot it will serve an endless stream of random data as fast as it can regardless of how much new entropy enters the system. This is what tools actually need, some other systems have provided this via a separate /dev/arandom. /dev/urandom still acts the same way it always has, it'll serve you the output of the CSPRNG regardless if it has had enough time to properly seed it with entropy yet (so may act more like a standard PRNG very early into the boot cycle).
loeg 5y ago
https://aka.ms/win10rng https://aka.ms/win10rng

ploxiln 5y ago

Stephan Müller has proposed his "LRNG" rewrite 5 years ago, and it was not well received by the linux random subsystem maintainer Ted Ts'o: https://lkml.org/lkml/2016/4/21/839 https://lkml.org/lkml/2016/4/21/839 but there has been a notable development in the subsystem this year, finally `/dev/random` blocks only before initialization, and never after! https://lore.kernel.org/lkml/20200131204924.GA455123@mit.edu/ https://lore.kernel.org/lkml/20200131204924.GA455123@mit.edu...

salmo 5y ago

This is something that has frustrated me for years. There has been no interest in modernizing the Linux PRNG really ever. This article doesn't go into more depth so I don't know if it's just tacking on more entropy sources and algorithm support or a real modernization. Windows, MacOS, every BSD, Solaris, etc. have moved past the (blocking) /dev/random vs /dev/urandom to more mathematically sound solutions. (Seriously, measuring entropy?) But Torvalds, Ts'o, etc. have blocked, belittled, or ignored any movement there. It's crazy that the OS that runs all the things essentially has a roll-your-own-crypto PRNG at its core rather than relying on actual experts for that. Unfortunately, it's "good enough" to not HAVE to change. Use /dev/random sparingly to seed your own PRNG, change your Java config to use /dev/urandom, or (shudder) use rngd to make it seed itself. At least once a year I hit some COTS product that craps itself under load blocking on /dev/random on a VM, causing an outage. Yes, it's a "worked on my laptop" problem, but an unnecessary rake to leave out in the garden.

gerdesj 5y ago
This is from early last year: https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/ "Removing the Linux /dev/random blocking pool"
jeltz 5y ago
Linux has also moved past it, but only quite recently. https://lwn.net/Articles/808575/ https://lwn.net/Articles/808575/
ploxiln 5y ago
Blocking /dev/random has been a problem that many people were interested about for a long time, and it has had alternatives: /dev/urandom since forever (though it has a big problem for some short period just after bootup), getentropy() since 2015 can do the right thing with the right options, and finally since 2020 /dev/random does the right thing - it only blocks until seeded, then gives unlimited secure random bytes. (I only learned about this 2020 update in this very thread!) My understanding is that /dev/random behavior persisted for so long only due to some dumb corporate/military compliance thing that some huge companies "needed". EDIT: apparently this was due to NIST standard SP800-90B and maybe German AIS 31, and the most recent idea is to forget them, and have orgs that really need the strange/problematic blocking behavior implement it in user-space.

jdlyga 5y ago

tl;dr the solution is a USB-powered cup of Yahtzee dice. There was some debate over the color of the dice and usb-c vs usb-a. But it will be included in the next kernel release and shipped out to every user of the linux kernel with the next update.

jeffbee 5y ago

QQ: why does this belong in the kernel at all?

JoachimS 5y ago
Two reasons. (1) The kernel itself needs access to good random numbers for its operation. (2) Having a source of random number is something many applications need, and just like other services (storage, communication) random numbers a good thing to provide. As the article shows, generating good random numbers generated based on physical entropy is a complex process. Not providing this as a service to applications would probably lead to many applications having bad random numbers. Just like we don't expect all applications to implement their own version of TCP. Note that applications may use PRNGs from a library, for example Clib. But unless you want just pseudo randomness you somehow need to get entropy/noise from the physical machine. And the service presented to the application (for example via /dev/random) provides that.
- JoachimS 5y ago
  Though of course, this could be in a userland library too. Just reading entropy from HW (exposed by the kernel). But the kernel still needs access to random number it can control and trust.

daneel_w 5y ago

I wonder why they just didn't take a cue from OpenBSD's arc4random solution years ago, instead of this drawn-out contortion.