Linus on /dev/random: "We actually know what we are doing. You don't."
nakedsecurity.sophos.com
Linus on /dev/random: "We actually know what we are doing. You don't."
1–10 of 77 posts
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#2I'd want to hear Linus responding to both the OP and Taylor. But quick thought: do people like Bruce Schneier ever read this file? I think in the next year or two we will see a huge number of research going into finding "backdoor", suggesting implementation weaknesses. I am not going to speculate too much about who is NSA mole or why certain code got into the codebase. I'm more interested in researchers to find more weaknesses, like how Barton Miller did by fuzzing unix programs back in the 90s! I wish I had enough knowledge to help out.
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#3I never followed this at all prior to reading this article so forgive me if this was covered outside the scope of this write-up, but...
If the CPU did give you a RDRAND value that was pre-baked to weaken the number it thinks you're going to XOR it against it, it would be easy to detect this by feeding RDRAND the same input state repeatedly and seeing if there is a pattern to what is spit out or if it is indeed statistically random... So why hasn't someone (who thinks RDRAND is a trap) done that instead of just claiming it could maybe be doing something fishy?
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#4[deleted]
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#5We 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 output of rdrand (because it's really some stream cipher with a known key or something), most people don't. Therefore, it wouldn't improve the randomness of the final stream from the NSA point of view, but it would from the point of view of any other attacker not in the secret. So I think it's fair to say it can't do harm and it can actually do some good.
See also the previous discussion:
https://news.ycombinator.com/item?id=6359892
The consensus seems to be that if the NSA can backdoor rdrand so deeply that it can keep track of the CPU state and the contents of the RAM then you might as well throw away the whole CPU, why would you choose to trust all instructions but rdrand? They could have compromised the interrupt vector, the syscall vector or anything else.
This feels like "rumor based cryptography" or more precisely "FUD based cryptography". We're just running in circles.
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#6I never followed this at all prior to reading this article so forgive me if this was covered outside the scope of this write-up, but... If the CPU did give you a RDRAND value that was pre-baked to weaken the number it thinks you're going to XOR it against it, it would be easy to detect this by feeding RDRAND the same input state repeatedly and seeing if there is a pattern to what is spit out or if it is indeed statis…
How would you distinguish actual randomness from the output of a CSPRNG with a known or weak seed? Patterns won't be apparent in either output.
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#7I never followed this at all prior to reading this article so forgive me if this was covered outside the scope of this write-up, but... If the CPU did give you a RDRAND value that was pre-baked to weaken the number it thinks you're going to XOR it against it, it would be easy to detect this by feeding RDRAND the same input state repeatedly and seeing if there is a pattern to what is spit out or if it is indeed statis…
How would you distinguish actual randomness from the output of a CSPRNG with a known or weak seed? Patterns won't be apparent in either output.
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 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.
...unless people think the chip is also detecting situations where you are actively trying to fool it by setting up repeated simulations of the same initial value to be XORed, which strains credibility way beyond what I'm willing to believe.
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#8I'd want to hear Linus responding to both the OP and Taylor. But quick thought: do people like Bruce Schneier ever read this file? I think in the next year or two we will see a huge number of research going into finding "backdoor", suggesting implementation weaknesses. I am not going to speculate too much about who is NSA mole or why certain code got into the codebase. I'm more interested in researchers to find more…
Bruce Schneier
I have all the respect for the guy, really, but then I read his guardian article "how to keep your data safe and secure" and mentions keeping "air gap" between computers with sensitive data but then he himself admits after all his methods and safeguards for the leaks he is working with, he uses Windows and usb-sticks to transfer (encrypted) files between them.
He uses Windows.
He uses Windows.
And he was claiming in the article that free and open source are better for security. Oh really, so your encrypted files on your usb-sticks for sure cant spread malware through your airgap through a file-system exploit? For sure it has never been done before that a file system could be used to take over an OSs internals, oh never.
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#9If you consider the title of the article, "Rudest man in Linuxdom", you understand very quickly that the article author is imposing their own moral on Linus, but that's OK because the author is a proven programming genius of greater skill than the person who invented Linux, git, etc.
...
Oh wait, he isn't. The author of the article is just another "tech blogger" that is interested in page views. So what's more interesting an article to write: one about RDRAND, or one about how mean, naughty and rude that ignorant "Linus Torvalds" person is? The second option will generate more page views so the choice is obvious.
Since the author of the article is quick to criticize Linus and his way of expressing himself, even going so far as to, in a bullet list, sentence Linus to community service for the crime of not being as kind, understanding and tolerant a person as the author, I'm going to do the same.
Hey, article author! If I were king, here's what I would want you to do:
* Write an operating system that is used by millions of people and powers a large part of the Internet (together with BSD and friends).
* Write a distributed CVS that is also used by millions of people.
* Stop writing bullet lists about people.
* Stop trying to attract hits to your tech blog and create something of use to the human species. How about rewriting the graphics support in the kernel or something?
* Criticize what people say, not how they say it.
I'm tempted to go on, but I know that the author has no interest in neither learning nor creating anything, only criticizing other people, so anything I write is for the enjoyment of HN (in addition to mine).
Re: Linus on /dev/random: "We actually know what we are doing. You don't."
#10I never followed this at all prior to reading this article so forgive me if this was covered outside the scope of this write-up, but... If the CPU did give you a RDRAND value that was pre-baked to weaken the number it thinks you're going to XOR it against it, it would be easy to detect this by feeding RDRAND the same input state repeatedly and seeing if there is a pattern to what is spit out or if it is indeed statis…
One counter argument I can think of:
The rougue RDRAND would become active only in a CPU which the back-door has been exploited. It wouldn't be active off-the-shelf.