News for hackers. Stuff that matters.
Re:Linux Hardening Guide by brobdingnagians on Thursday December 31, 2020 @03:58AM (#25590915)
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.

Re:Linux Hardening Guide by necheffa on Thursday December 31, 2020 @07:16AM (#25591963)
It 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.

Re:Linux Hardening Guide by tremon on Thursday December 31, 2020 @07:22AM (#25592004)
That'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).
Re:Linux Hardening Guide by px43 on Thursday December 31, 2020 @02:59PM (#25596463)
A 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.