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

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.<p>Regarding &quot;(I&#x27;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&#x27;t reduce it.)&quot;: I think it&#x27;s fair to say it would, in practice.<p>Even if the NSA knows how to predict the output of rdrand (because it&#x27;s really some stream cipher with a known key or something), most people don&#x27;t. Therefore, it wouldn&#x27;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&#x27;s fair to say it can&#x27;t do harm and it can actually do some good.<p>See also the previous discussion:<p><a href="https://news.ycombinator.com/item?id=6359892" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6359892</a><p>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 <i>but</i> rdrand? They could have compromised the interrupt vector, the syscall vector or anything else.<p>This feels like &quot;rumor based cryptography&quot; or more precisely &quot;FUD based cryptography&quot;. We&#x27;re just running in circles.

This whole discussion about rdrand reminds me of people arguing about what strength the secondary lock on their upstairs back window should be when the downstairs floor has single pane glass windows all around.<p>Even if rdrand <i>is</i> backdoored it would have to be a significant supplier of entropy in the resulting random number for this to be a meaningful attack vector, as soon as you mix it with other (good enough, large enough) sources of entropy you get a situation where some other attack is more likely to be far more feasible than to use the knowledge about some of the bits that rdrand contributes to the entropy pool.<p>Such as:<p><pre><code> - good old b&amp;e and placing a keylogger or hardware bug (very easy to hide in a keyboard) - a compromised bit of the OS - compromising the application that you use to encrypt your messages or finding a significant weakness in the application. - doing any of the above with the recipient</code></pre>

Instead of discussing on LKML or other forums, he decides to create <i>a petition on change.org</i>. Got what it deserved.<p>Somebody should be apologizing here, and it isn&#x27;t Linus.

Please do not submit professional troll articles.

If you think RDRAND is examining the L1 and registers in order to derandomise it, why wouldn&#x27;t the evil chip just skip bothering with RDRAND and instead just attack that random buffer it knows how to find...?

When I first learned about RDRAND I was thrilled because I naively assumed this would be just a hardware RNG with direct link to the CPU register vector capable of delivering randomness with a speed of cache hits or better. This would be an end to all struggles with non-crypto PRNGs (which have zyllions of uses in science, mostly in Monte Carlo methods and machine learning, but also some in &quot;consumer computing&quot; like raytracing).<p>But no, Intel made a sluggish hardware PRNG that occasionally eats some thermal bits just to make crypto guys happy -- and bang, now everybody thinks it is an NSA backdoor.

I&#x27;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 &quot;backdoor&quot;, 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&#x27;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.

Is rdrand really the very last stage? As in the output is &quot;stream XOR rdrand&quot;? If that is really the case it puts full, 100% trust in Intel not to insert a backdoor. It wouldn&#x27;t even be hard. All the CPU need do is check for the xor operation used with rdrand as an operand, and instead of performing the xor, substitute the backdoored pseudo-random stream instead. No runtime monitoring of internal state would be necessary, the whole thing could be done at the assembly to microcode translation layer.

Where do I go to elect this guy &quot;King&quot;? All of his suggestions were reasonable and measured.

If I remember right, the original reasoning why this could be a problem was something along the lines:<p>You are using sources s1, s2, s3. Then final result is combination c(s1,s2,s3). Now somebody screws up something and the sources s1 and s2 start returning just constant values. If you were just using s1 and s2 you would immediately notice this. However since you are combining all three, you are getting something that looks good but what might not be really secure if the source s3 is compromised.<p>(I think this came up in some HN discussion some weeks ago)<p>I&#x27;m not familiar with the Linux implementation so I don&#x27;t know if this has any meaning there.

I 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...<p>If the CPU did give you a RDRAND value that was pre-baked to weaken the number it thinks you&#x27;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&#x27;t someone (who thinks RDRAND is a trap) done that instead of just claiming it could maybe be doing something fishy?

It could be summed up as is: either you have a test that shows that rdrand has got problematic behavior or you shut up.<p>Backdooring rdrand is of little to no interest given how PRNGs are built.

Good article if only for &quot;bucket of digital slurry.&quot;

The way things are, people are going to post on HN if Linus farts and others would upvote.

Why is this _AGAIN_ here? This has been posted like 50 times already during a couple of days. And what Linus says isn&#x27;t actually even anything bad that should create this kind of stupid fuzz.

If you consider the title of the article, &quot;Rudest man in Linuxdom&quot;, you understand very quickly that the article author is imposing their own moral on Linus, but that&#x27;s OK because the author is a proven programming genius of greater skill than the person who invented Linux, git, etc.<p>...<p>Oh wait, he isn&#x27;t. The author of the article is just another &quot;tech blogger&quot; that is interested in page views. So what&#x27;s more interesting an article to write: one about RDRAND, or one about how mean, naughty and rude that ignorant &quot;Linus Torvalds&quot; person is? The second option will generate more page views so the choice is obvious.<p>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&#x27;m going to do the same.<p>Hey, article author! If <i>I</i> were king, here&#x27;s what I would want you to do:<p>* Write an operating system that is used by millions of people and powers a large part of the Internet (together with BSD and friends).<p>* Write a distributed CVS that is also used by millions of people.<p>* Stop writing bullet lists about people.<p>* 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?<p>* Criticize what people say, not how they say it.<p>I&#x27;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).