3 ms·
That source you shared seems to show that there could be a problem with tainted RDRAND, since it is xored in at the end of the function, and the linked email th
by brobdingnagians 6y ago
That source you shared seems to show that there could be a problem with tainted RDRAND, since it is xored in at the end of the function, and the linked email thread has comments by "maintainer of record (me) for the Linux RNG" who "quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections.
From a quick skim of current sources, much of that has recently been rolled back"
At the very least, that looks like there might be something in it. I don't know crypto well enough to say for sure, but it looks like Linus needs to re-read rand.h from what that article says about the state of the comments and previous rolled back changes from Intel. It does make one wonder if Linus' arrogance and rudeness could be used as cover for a genuine backdoor.
- necheffa 6y agoIt is xor'd because all entropy sources are xor'd. That's just the design of /dev/random. And because of this, Intel or whoever would need to have weakened each and every entropy source you use to make anything of it.
- tremon 6y agoThat's not true, because the RDRAND entropy is mixed in last. So once you're under the assumption that RDRAND is nefarious, the microcode only needs to detect the rdrand-to-xor pattern to make the entire entropy pool predictable (for example: by setting the non-rdrand input to the xor operation to zero it could disable all other entropy sources).
- px43 6y agoA microcode backdoor capable of reading the existing entropy pool state is going to be a hell of a lot more powerful than a RDRAND backdoor, to the point of making a RDRAND backdoor worthless.