4 ms·

All Intel and AMD chips come with a hardware RNG today: the RDRAND and RDSEED instructions. RDRAND is kinda-sorta like /dev/urandom, while RDSEED is /dev/rando

All Intel and AMD chips come with a hardware RNG today: the RDRAND and RDSEED instructions. RDRAND is kinda-sorta like /dev/urandom, while RDSEED is /dev/random with stronger entropy guarantees. Linux didn't want to "trust" this hardware, for whatever reason. I guess there was that one time an AMD bug in the instruction returned all-zeros (or something similar). But as "long as the instruction is properly working", it is... well... working, lol. But its not like its really possible to test if its working correctly. -------- From that perspective, a hardware RNG needs to be "large" and "discrete" enough for humans to easily test and prove that its working, to create trust. Otherwise, hardware and/or firmware bugs could lead to a security problem. EDIT: if you are at a mass produced but don't verify kinda person, then you might as well use RDSEED instructions to get her entropy. Intel/AMD probably are good enough to prevent firmware / hardware bugs. I know that VMs also have an issue here: whether or not to make RDSEED deterministic/predictable or not. Should the future RDSEED instructions be saved in a VM snapshot?

jnwatson 4y ago
You can (and are required to in certain environments) test for basic failures in your hardware RNG. The AMD bug was bad not because of the bug, but because it was obvious they had no built-in-test functionality.
garaetjjte 4y ago
>RDRAND is kinda-sorta like /dev/urandom, while RDSEED is /dev/random with stronger entropy guarantees. /dev/urandom and /dev/random is almost the same nowadays, the only difference is that random will block after boot until enough entropy is collected, but it never "runs out" of entropy anymore.
adrian_b 4y ago
Any hardware RNG that is included in a CPU or any other complex integrated circuit cannot be trusted, because it is impossible to verify that it is truly a RNG and not a pseudo-RNG that implements backdoors. The only hardware RNGs that can be trusted are those that use an analog-digital converter (e.g. one of the ADCs included in any microcontroller, or the audio microphone input of a computer) and a discrete analog noise source, e.g. a diode or a resistor, because their components can be tested separately, to verify that they do what they claim to do. Nevertheless, the output of the hardware RNGs provided by the Intel or AMD CPUs can be used in a reasonably secure way if the supposedly random values are never used directly, but they are passed through a cryptographic hash, e.g. SHA-256. Even SHA-1 is completely adequate for this special purpose, where collision-resistance does not matter (and it is faster than any other secure hashes in the ARM, AMD or Intel CPUs with SHA-1 instructions). Even better, the supposedly random value could be hashed together with the timestamp read from the TSC, or just with the value of a counter incremented after generating a random number, for additional unpredictability. One can add to the hash a unique computer identifier, e.g. the MAC address of the first Ethernet interface. In this case, distinct sequences of uniformly-distributed pseudo-random numbers will continue to be produced even in computers where the hardware RNG remains stuck to a constant value, as it happened in some buggy AMD Zen models. The hashing (with a secure hash algorithm) of the RNG output destroys any hidden structure that might have been exploitable by the designers of the hardware RNG, while preserving the uniform distribution of the random numbers.
- eternityforest 4y ago
  I don't think straight hashing is enough. Suppose the internal RNG is just AES in counter mode(Assume somehow they can persist state internally) They then know the full list of numbers it will ever make. They also know the full list of hashed numbers it will ever make, if they know the hashed block size, which they do if they know what software you are using. Now when you make a private key they just try all trillion possible offsets into the list of numbers it could likely be, hash those 32 bytes or whatever the block size is, and see if that's your key. But I am not the paranoid type nor do I currently have things to hide from anyone with access to Intel backdoors, so I'm not too worried. I think Linux has it pretty well figured out mixing in other sources just to be sure.
  - adrian_b 4y ago
    It is completely impractical to store a table of hash values that is large enough to be able to reverse the hash. No HDD will be big enough. Moreover, as I have already written, this possibility is easily circumvented by also hashing a time-varying value and a value unique to each computer, not only the RNG output.
    - eternityforest 4y ago
      If the unique value is secret, yes. Otherwise there is no need to store a table of values. If a home type PC is used for a year, there will be a finite amount of randomness used from the HW generator in total. Probably under a terabyte I would guess. Maybe under a gigabyte. If you are doing something like looking for an encryption key, you know it's somewhere in that terabyte, which you can generate too, then put every possible block through your hash, and try it. You don't even need to store anything, you can just generate them since they're deterministic. And if the backdoor is based on a block cipher in in counter mode or something like that, you can do it all in parallel on FPGAs in seconds if you're a billionaire.
- bscphil 4y ago
  > Nevertheless, the output of the hardware RNGs provided by the Intel or AMD CPUs can be used in a reasonably secure way if the supposedly random values are never used directly, but they are passed through a cryptographic hash, e.g. SHA-256. Even SHA-1 is completely adequate for this special purpose Why would you go to any of this trouble and not just XOR the output of RDRAND into the starting seed (based on hardware entropy) for your PRNG (/dev/urandom)? Even if it turns out that Intel is providing a single static value (like all zeros) to every device ever, that's not going to help them figure out the starting seed if the rest of the entropy is from a sufficiently secure source.
ur-whale 4y ago
> for whatever reason. For very good reasons. The circuit is opaque and vendor specific. The OneRNG presented in the article is claimed to be verifiable, at the very least. Intel and other chip vendors don't even bother making the claim.
JoachimS 4y ago
It wasn't that RDAND wasn't trusted as source of randomness in Linux. It wasn't trusted enough to replace the whole RNG chain - with entropy collection, seed extraction and DRBG/CSPRNG. Which to me was and is perfectly reasonable. Replacing an open source chain that can be fed with entropy from several sources and mixed together, with a black box that is hard to inspect and trust.

jnwatson 4y ago

You can (and are required to in certain environments) test for basic failures in your hardware RNG. The AMD bug was bad not because of the bug, but because it was obvious they had no built-in-test functionality.

garaetjjte 4y ago

>RDRAND is kinda-sorta like /dev/urandom, while RDSEED is /dev/random with stronger entropy guarantees. /dev/urandom and /dev/random is almost the same nowadays, the only difference is that random will block after boot until enough entropy is collected, but it never "runs out" of entropy anymore.

adrian_b 4y ago

Any hardware RNG that is included in a CPU or any other complex integrated circuit cannot be trusted, because it is impossible to verify that it is truly a RNG and not a pseudo-RNG that implements backdoors. The only hardware RNGs that can be trusted are those that use an analog-digital converter (e.g. one of the ADCs included in any microcontroller, or the audio microphone input of a computer) and a discrete analog noise source, e.g. a diode or a resistor, because their components can be tested separately, to verify that they do what they claim to do. Nevertheless, the output of the hardware RNGs provided by the Intel or AMD CPUs can be used in a reasonably secure way if the supposedly random values are never used directly, but they are passed through a cryptographic hash, e.g. SHA-256. Even SHA-1 is completely adequate for this special purpose, where collision-resistance does not matter (and it is faster than any other secure hashes in the ARM, AMD or Intel CPUs with SHA-1 instructions). Even better, the supposedly random value could be hashed together with the timestamp read from the TSC, or just with the value of a counter incremented after generating a random number, for additional unpredictability. One can add to the hash a unique computer identifier, e.g. the MAC address of the first Ethernet interface. In this case, distinct sequences of uniformly-distributed pseudo-random numbers will continue to be produced even in computers where the hardware RNG remains stuck to a constant value, as it happened in some buggy AMD Zen models. The hashing (with a secure hash algorithm) of the RNG output destroys any hidden structure that might have been exploitable by the designers of the hardware RNG, while preserving the uniform distribution of the random numbers.

eternityforest 4y ago
I don't think straight hashing is enough. Suppose the internal RNG is just AES in counter mode(Assume somehow they can persist state internally) They then know the full list of numbers it will ever make. They also know the full list of hashed numbers it will ever make, if they know the hashed block size, which they do if they know what software you are using. Now when you make a private key they just try all trillion possible offsets into the list of numbers it could likely be, hash those 32 bytes or whatever the block size is, and see if that's your key. But I am not the paranoid type nor do I currently have things to hide from anyone with access to Intel backdoors, so I'm not too worried. I think Linux has it pretty well figured out mixing in other sources just to be sure.
- adrian_b 4y ago
  It is completely impractical to store a table of hash values that is large enough to be able to reverse the hash. No HDD will be big enough. Moreover, as I have already written, this possibility is easily circumvented by also hashing a time-varying value and a value unique to each computer, not only the RNG output.
  - eternityforest 4y ago
    If the unique value is secret, yes. Otherwise there is no need to store a table of values. If a home type PC is used for a year, there will be a finite amount of randomness used from the HW generator in total. Probably under a terabyte I would guess. Maybe under a gigabyte. If you are doing something like looking for an encryption key, you know it's somewhere in that terabyte, which you can generate too, then put every possible block through your hash, and try it. You don't even need to store anything, you can just generate them since they're deterministic. And if the backdoor is based on a block cipher in in counter mode or something like that, you can do it all in parallel on FPGAs in seconds if you're a billionaire.
bscphil 4y ago
> Nevertheless, the output of the hardware RNGs provided by the Intel or AMD CPUs can be used in a reasonably secure way if the supposedly random values are never used directly, but they are passed through a cryptographic hash, e.g. SHA-256. Even SHA-1 is completely adequate for this special purpose Why would you go to any of this trouble and not just XOR the output of RDRAND into the starting seed (based on hardware entropy) for your PRNG (/dev/urandom)? Even if it turns out that Intel is providing a single static value (like all zeros) to every device ever, that's not going to help them figure out the starting seed if the rest of the entropy is from a sufficiently secure source.

ur-whale 4y ago

> for whatever reason. For very good reasons. The circuit is opaque and vendor specific. The OneRNG presented in the article is claimed to be verifiable, at the very least. Intel and other chip vendors don't even bother making the claim.

JoachimS 4y ago

It wasn't that RDAND wasn't trusted as source of randomness in Linux. It wasn't trusted enough to replace the whole RNG chain - with entropy collection, seed extraction and DRBG/CSPRNG. Which to me was and is perfectly reasonable. Replacing an open source chain that can be fed with entropy from several sources and mixed together, with a black box that is hard to inspect and trust.