> From: [email protected] [mailto:discuss- > [email protected]] On Behalf Of Kent Borg > > As I said, urandom driver details change, but last I looked the Intel > RNG is only Xor-ed into the urandom driver's output. It can't hurt--even > if the NSA knows every bit it ever outputs--and it might help (maybe the > NSA slips some in tracking your RNG hardware's state). > > But it won't help you with your entropy accounting, it is not credited > to the pool. Actually, I think the detail of how they use Intel's RNG > changed, but it isn't being trusted. It is only a can't-hurt extra in > the mix. > > (When the Snowden stuff came down, Ted T'so, the original and recent > urandom guy, was very relieved that, despite pressure, he didn't accept > Intel's RNG output on faith.)
Uh oh. A lot of the above is either inaccurate or misleading - because it appears, you've been misled and fell for it. I've studied this very specific topic a lot for the purposes of creating tinhatrandom. First and foremost, before addressing the simple facts of whether or not the XOR can be harmful, there's a bigger issue, which goes like this: You said "it isn't being trusted." This is the opposite of true. If it weren't being trusted, it would be fed into the entropy pool just like everything else, so it would then be forced through all the mixing & hashing algorithms in order to eliminate the untrusted entropy source's ability to maliciously manipulate the output in a controlled way. Specifically by bypassing the pool and getting XOR'd with the output, it *is* being trusted to be non-malicious. (See below). Ted T'so's comment was "I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction." In this comment, he's the tail wagging the dog. He's creating the soundbite "I resisted pressure from Intel," but at the same time, *what* he resisted pressure to wasn't sufficient. Yes they resisted eliminating all the other entropy sources. (Did you ever hear that Intel pressured them to rely *exclusively* on RDRAND and eliminate all the other entropy sources? I guess it must have been private conversation.) No, they didn't resist giving Intel the ability to completely undermine the other entropy sources. (Again, as explained below). The "bigger" problem than the XOR problem, is the undermining by Linus and mishandling of community review or community contribution. First, Matt Mackall (the "other random guy") strenuously objected to Intel's patches, which Linus accepted over his insistent complaints, and caused Matt to quit in protest. Later, Kyle Condon (a little guy on the internet) wrote an open letter to Linus begging him to undo the RDRAND XOR code, supported by a copy of random.c with added comments identifying what the security problems are. Linus responded in a bully-ish meanspirited way which not only didn't address any of the technical concerns, but just launched into a tyrade of a bunch of personal insults, including "Go read random.c" which tends to suggest either Linus is insane, or didn't bother reading the complaint. The original petition was withdrawn, tail between the legs (got #rekt by the big famous powerful bully who maintains ultimate decision making power over the code, who entrenched himself into a position so deeply there's no hope of ever getting him back out of it). And for some reason, the media basically accepted that as a conclusion. (Which is journalistically embarrassing.) It's as if some little guy on the internet got on CNN to expose a huge safety flaw in a major car manufacturer, and then the manufacturer's spokesperson launched into a bunch of foul language insults, and then it was case closed. Bully wins. The actual fact of the matter, as I described on http://tinhatrandom.org is that if you receive two supposedly random numbers from Random Source A, and Random Source B, and you're going to just mix them together with XOR, then you definitely have a security problem if *either* A or B is a malicious adversary. The most obvious way to demonstrate this is as follows: Suppose Source A gathers entropy from mouse movements and delivers those bytes to you, claiming "these are random bytes." Now suppose Source B is a malicious adversary, who also gathers entropy from mouse movements, and delivers the same exact output as Source A, because Source B knows, when you XOR those together, you're going to get all zeros as your output, which is clearly very non-random. The malicious entity could do much more clever stuff, much less obviously detectable, which would have the effect of having absolute control over the resultant random output. The malicious entity could very easily reduce every 128 bits of entropy to 16 bits (or any other arbitrary strength). The result would still appear to be random, would pass all random analysis tests, and basically be undetectable except by the adversary who would be able to trivially crack your codes. In order to prevent such a weakness, you *must* perform some cryptographic operations (such as hashing or enciphering) on the supposed input entropy sources, before mixing them, and of course they must be mixed in such a way that an active adversary controlling less than all of the inputs cannot have any meaningful control over the output. The goal *must* be, to make the only possible attack one in which the adversary requires (a) access to all the inputs in order to generate any sort of meaningful attack, and (b) with no meaningful control on the output, the adversary must store and/or transmit all the random numbers generated, in order to make use of that knowledge for an attack. While it's absolutely possible for a malicious CPU or other motherboard component to carry out such an attack, the use of storage and/or communication channels to transmit your random numbers to adversaries would be much more obviously detectable, much more blatantly demonstrative of premeditated malicious intent, and much more criminally undefendable by an organization such as Intel or Microsoft or Linus Torvalds. _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
