Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus on /dev/random: "We actually know what we are doing. You don't."

nakedsecurity.sophos.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Linus on /dev/random: "We actually know what we are doing. You don't."

#71

Post by dlitz »

simias wrote: post #5

We allow the wild web to have access to our closed source GPU driver blobs but we elaborate tinfoil hat theories about rdrand. This is insane. Regarding "(I'm not sure I agree with Linus that mixing in a known-tainted RDRAND stream would nevertheless invariably improve randomness, but on the surface, it shouldn't reduce it.)": I think it's fair to say it would, in practice. Even if the NSA knows how to predict the ou…

> why would you choose to trust all instructions but rdrand

Presumably, there are limits to the amount of silicon that Intel/NSA can devote to backdooring everyone. Since other instructions are supposed to behave deterministically, it could be expensive to backdoor them in a way that would not easily be discovered.

On the other hand, RDRAND could be a straightforward Dual_EC_DRBG implementation, which would be a very cheap and effective backdoor that would also have the nice benefit of keeping people's communications secure against everyone except the NSA.

Of course, there's also the possibility that there's no backdoor, but that the implementation is still buggy.

There's no reason why our trust in the hardware has to be all or nothing.

Re: Linus on /dev/random: "We actually know what we are doing. You don't."

#72

Post by georgemcbay »

Perseids wrote: post #21
georgemcbay wrote: post #7

Earlier quoted context omitted.

The gist of the argument as I understand it is that some people think Intel's chip (at the chip level) is taking a look at data that the RDRAND result will be used as an XOR against and using that to mess with the result RDRAND returns in some way to weaken the overall random number. If this were true and you set up a repeatable test situation in which you force the other parts of the RNG to generate the same numbers…

Actually that is quite simple. For simplicity let us assume RDRAND will only attack the Linux RNG. Now RDRAND first generates its own weak random stream w_k. When it predicts that Linux will generate l_k it outputs l_k xor w_k thus the final output of the Linux RNG will be w_k. As w_k looks random for everyone who does not have the private key you cannot check that there is anything wrong with w_k or w_k xor l_k.

"For simplicity let us assume RDRAND will only attack the Linux RNG."

Assuming the chip is detecting that the Linux RNG is in play is already way out of the realm of simplicity and frankly way beyond what a company like Intel is likely to be able to keep secret given the number of engineers that would have to be aware of this complex functionality.

This whole conspiracy theory hinges on some wild claims that I haven't seen substantiated in the least.

Re: Linus on /dev/random: "We actually know what we are doing. You don't."

#73

Post by topynate »

jgrahamc wrote: post #38
makomk wrote: post #31

Earlier quoted context omitted.

Did you actually look at how the Linux kernel is mixing RDRAND output with other randomness, or read the comments by the author of the original change.org petition? Because of the way Linux mixes RDRAND output with other entropy using XOR, a malicious RDRAND implementation can easily make the output of /dev/random totally determinisitc whilst being completely indistinguishable from a correctly-functioning implementat…

All it has to do is detect the code sequence in question and XOR the output of RDRAND with the randomness from the other entropy sources before returning it. How is that going to work? i.e. how is RDRAND going to 'detect the code sequence'?

RDRAND wouldn't, the control unit would. Whenever it sees the XOR macroinstruction it checks the second operand to see if it's RDRAND. If so, it doesn't order an XOR; rather it just copies the RDRAND value to the first operand address.

That's the straightforward way of doing it. The 'finesse' would be to leave RDRAND as a secure random source, but in the case of it being used as an operand of XOR, simply to ignore RDRAND entirely, substituting an insecure stream. The advantage, other than reduced risk of detection, would be that asynchronous access to RDRAND wouldn't scramble the otherwise breakable output.

Re: Linus on /dev/random: "We actually know what we are doing. You don't."

#74

Post by yeukhon »

antocv wrote: post #20
jamesrom wrote: post #17

Earlier quoted context omitted.

It's still good advice. In fact, unless you audit the source of your OS, it's compiler, hardware and any software you need to use you can't really make any guarantees either.

I can make you the guarantee that Microsoft is actively cooperating with the NSA and has backdoors in Windows. I can guarantee you that few people have access to the Windows source to check it. I can also guarantee you that many more people have access and have audited the source code of a GNU/Linux system. I cant guarantee you that GNU/Linux doesnt have backdoors. But for all intents and purposes it is just plain Wr…

Sorry. I think you are too paranoid. You are. Close source can have backdoor and open source can have backdoor too. I like to use Linux and my Mac to do programming work, but it doesn't mean I don't care about Windows.

If you think Linux has less chance getting backdoor, well, look at all the speculation we got these days. If NSIT cryptographic standard has reduced security as many people believe, then your communicate is dead.

If you believe that all ISP are cooperating with the US government here in the US, why the hell are you still using the Internet as we know it? You are guaranteeing that only an open source system will not have a backdoor while a closed source must have. Microsoft has collaboration with NSA in one way or another. Is that a secret? Most of their "collaboration" probably come from business things like military-kind projects. They might have backdoor. But guarantee is a big assumption. If you don't have solid proof then you are making false accusation.

It's like saying because your friend shakes hands and hang out with a cold-blood murder he must be a cold-blooded person too. Plain wrong, ignorant and simply stupid.

Security has a trust involved. If you don't trust your USB, your own product, then you will not get any security. There is nothing wrong with transferring things between usb and windows computer. It's fine. You can still run SCP, SSH over your Windows socket. Is that now weaker because damn MS is working with NSA as you say?

Someone give this man a cookie because we are obviously living in an fantasy.

If you think your ipod, your laptop don't have backdoor according to how MS and Intel are working with NSA, you are contradicting. Stop using the Internet and stop using anything. Then you are safe.

Re: Linus on /dev/random: "We actually know what we are doing. You don't."

#75

Post by makomk »

idProQuo wrote: post #42
makomk wrote: post #31

Earlier quoted context omitted.

Did you actually look at how the Linux kernel is mixing RDRAND output with other randomness, or read the comments by the author of the original change.org petition? Because of the way Linux mixes RDRAND output with other entropy using XOR, a malicious RDRAND implementation can easily make the output of /dev/random totally determinisitc whilst being completely indistinguishable from a correctly-functioning implementat…

I keep hearing this argument, but I don't feel like it's relevant to RDRAND. Let's say the numbers are generated by by XORing RDRAND as "a" and the other parts as "b", such that for any given call: /dev/random = a XOR b If the NSA only knows "a", that's fine, "b" is still pretty random. They can't compromise the randomness of "b" unless they know "b". Now if they know "b", then we're screwed whether we use RDRAND or…

There's a difference between the NSA being able to add a malicious circuit into a CPU that has access to "b" and being able to leak the value of "b" to systems they control. Thankfully, in the case of RDRAND they don't have to do the latter - they can just neutralize the effect of "b" on the result on the CPU itself.

Re: Linus on /dev/random: "We actually know what we are doing. You don't."

#76

Post by Perseids »

mbq wrote: post #68
Perseids wrote: post #39

Earlier quoted context omitted.

You think 500MB/s [1] is slow? Or are you concerned with the latency of each call? Also I don't understand why you rant against PRNGs. Do you know that this stretching of actual random data makes RDRAND considerable faster than using actual randomness? [1]Source: http://stackoverflow.com/questions/10484164/what-is-the-late...

This 500MB/s a merged stream when using all cores, I got like 140MB/s on one (from my answer in the SO thread you linked). And I'm not ranting, I'm just crying over a lost opportunity. Nowadays you must spend time to think which PRNG to use and how to implement it to satisfy some quality/speed trade-off; an RNG (infinite cycle by design) directly connected to CPU (no transfer bottlenecks) that passes Die Hard (read r…

> And I'm not ranting

Sorry if I offended you.

I'm still surprised that poses a challenge for your applications. I thought fast non-cryptographic RNGs were a solved problem. How much random data do you generate? If you use a significant amount of CPU just for that I doubt it would be feasible for Intel to build a cryptographically secure RNG with the same throughput without significant extra costs (think one extra core). (I'm no expert on that subject though.)

Re: Linus on /dev/random: "We actually know what we are doing. You don't."

#77

Post by Perseids »

georgemcbay wrote: post #72
Perseids wrote: post #21

Earlier quoted context omitted.

Actually that is quite simple. For simplicity let us assume RDRAND will only attack the Linux RNG. Now RDRAND first generates its own weak random stream w_k. When it predicts that Linux will generate l_k it outputs l_k xor w_k thus the final output of the Linux RNG will be w_k. As w_k looks random for everyone who does not have the private key you cannot check that there is anything wrong with w_k or w_k xor l_k.

"For simplicity let us assume RDRAND will only attack the Linux RNG." Assuming the chip is detecting that the Linux RNG is in play is already way out of the realm of simplicity and frankly way beyond what a company like Intel is likely to be able to keep secret given the number of engineers that would have to be aware of this complex functionality. This whole conspiracy theory hinges on some wild claims that I haven'…

As far as I have followed the discussion there are no hard facts or claims at all, just the general suspicion against a completely closed system of an US company.

I, too, don't believe that Intel adaptively generates its RNG to spoil the Linux RNG. But be reminded that what would have been wild conspiracy theories just half a year ago is now common believe (NSA deliberately introducing vulnerabilities in software and even in cryptographic standards, routinely by-passing TLS).

Given all we know (and don't know) I think it would be prudent to mix Intel's RNG with the other randomness sources using a cryptographically strong primitive and not just XOR. Personally I'm enthusiastic about Keccak as a reseedable RNG, but these modes will probably be standardized no earlier than fall 2014.

> Assuming the chip is detecting that the Linux RNG is in play is already way out of the realm of simplicity

I meant simplicity of my argument. As an answer to this paragraph I argued that it is indeed possible to generate malicious output that appears completely random:

> If this were true and you set up a repeatable test situation in which you force the other parts of the RNG to generate the same numbers prior to RDRAND and then did the RDRAND and captured the results then I don't see how one could argue RDRAND is compromised in this way if the results coming out of it over time even appear to be statistically random.

Post reply on HN