3 ms·

It's preferred to use RDSEED and use that as a seed, instead of implicitly trusting the output of RDRAND. Mix it with user entropy (or system entropy). Some sa

It's preferred to use RDSEED and use that as a seed, instead of implicitly trusting the output of RDRAND. Mix it with user entropy (or system entropy). Some say RDRAND is a backdoor (and after Dual EC, it would not particularly surprise me). This is why RDRAND doesn't exist in Linux (or, maybe isn't the only source of entropy?): https://www.linux-magazine.com/Online/News/Linus-Says-No-Backdoor-in-Linux https://www.linux-magazine.com/Online/News/Linus-Says-No-Bac... Not sure the security implications of using poisoned seeds in addition to truly random seeds in an RNG. Some say that it's okay, because it cannot reduce security, only not increase it. But if the CPU RDRAND instruction is backdoored, couldn't the RNG instructions be intercepted and replaced so that RDRAND is the only seed? But, if your CPU is backdoored, why even bother with anything? etc, etc etc. This discussion could go on for a while.

foxfluff 5y ago
> But if the CPU RDRAND instruction is backdoored, couldn't the RNG instructions be intercepted and replaced so that RDRAND is the only seed? If the CPU is going to detect and subvert your soft PRNG, it can do that whether you use RDRAND or not.
- not2b 5y ago
  RDRAND is a microcoded instruction. The chipmaker does not publish that code, but they absolutely control what it does. If it has any flaws, whether deliberate or accidental, you can't fix them (the processor vendor might be able to fix it with a microcode update, but no one else can). That's why it isn't used. Your soft PRNG is an algorithm and a relatively simple one at that. You can test it, and verify that you get exactly the same sequence for a given seed whether you use a processor from Intel, AMD, ARM or someone else. Trying to detect and back door it would probably break a lot of other code. The bad guys would probably choose to attack you in a different way.
denton-scratch 5y ago
The issue isn't whether RDRAND is backdoored; it's that the output from the RDRAND circuitry is fed directly to an AES whitener, and the only thing you can test about the RDRAND output is the whitened output from AES. Well, the output from AES is by definition indistinguishable from randomness, unless you have the key. So to test a TRNG, you need access to the input to the whitener. Intel doeesn't provide that access. So the hardware might be producing a continuous stream of zeroes, and you'd never know from examining the output of the whitener. I believe Intel chips with RDRAND have been inspected using electron microscopes, and no flaw has been found in the hardware (I think it's two free-running oscillators whose outputs are sampled and XORed).
- foxfluff 5y ago
  The other problem with RDRAND is that you just can't trust them to get it right. How about always returning 0xffffffff? https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/ https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd... How about a bunch of collisions? https://github.com/systemd/systemd/issues/18184 https://github.com/systemd/systemd/issues/18184 Thanks, AMD...

foxfluff 5y ago

> But if the CPU RDRAND instruction is backdoored, couldn't the RNG instructions be intercepted and replaced so that RDRAND is the only seed? If the CPU is going to detect and subvert your soft PRNG, it can do that whether you use RDRAND or not.

not2b 5y ago
RDRAND is a microcoded instruction. The chipmaker does not publish that code, but they absolutely control what it does. If it has any flaws, whether deliberate or accidental, you can't fix them (the processor vendor might be able to fix it with a microcode update, but no one else can). That's why it isn't used. Your soft PRNG is an algorithm and a relatively simple one at that. You can test it, and verify that you get exactly the same sequence for a given seed whether you use a processor from Intel, AMD, ARM or someone else. Trying to detect and back door it would probably break a lot of other code. The bad guys would probably choose to attack you in a different way.

denton-scratch 5y ago

The issue isn't whether RDRAND is backdoored; it's that the output from the RDRAND circuitry is fed directly to an AES whitener, and the only thing you can test about the RDRAND output is the whitened output from AES. Well, the output from AES is by definition indistinguishable from randomness, unless you have the key. So to test a TRNG, you need access to the input to the whitener. Intel doeesn't provide that access. So the hardware might be producing a continuous stream of zeroes, and you'd never know from examining the output of the whitener. I believe Intel chips with RDRAND have been inspected using electron microscopes, and no flaw has been found in the hardware (I think it's two free-running oscillators whose outputs are sampled and XORed).

foxfluff 5y ago
The other problem with RDRAND is that you just can't trust them to get it right. How about always returning 0xffffffff? https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/ https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd... How about a bunch of collisions? https://github.com/systemd/systemd/issues/18184 https://github.com/systemd/systemd/issues/18184 Thanks, AMD...