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

41–50 of 77 posts

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

#41

Post by makomk »

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'?

Only Intel engineers know exactly how to do this and I doubt they're allowed to reveal hardware internals, but at the point RDRAND actually executes the next fewt instructions should have already been decoded and the data flow between them analyzed. In theory it's not terribly hard to use that information to change the behaviour of RDRAND.

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

#42

Post by idProQuo »

makomk wrote: post #31
jacquesm wrote: post #16

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. Even if rdrand is 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…

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 not, and safe encryption using Intel chips is just impossible. However I don't think anybody is suggesting that.

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

#44

Post by topynate »

Is rdrand really the very last stage? As in the output is "stream XOR rdrand"? If that is really the case it puts full, 100% trust in Intel not to insert a backdoor. It wouldn'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.

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

#45

Post by simias »

makomk wrote: post #41
jgrahamc wrote: post #38

Earlier quoted context omitted.

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'?

Only Intel engineers know exactly how to do this and I doubt they're allowed to reveal hardware internals, but at the point RDRAND actually executes the next fewt instructions should have already been decoded and the data flow between them analyzed. In theory it's not terribly hard to use that information to change the behaviour of RDRAND.

Honestly, and for lack of a more suitable expression, put up or shut up. If you think rdrand actually reads back the output of the RNG from RAM in order to nullify it, then show it.

It's actually possible, you can verify that the timing of the instruction conforms to what it's supposed to be doing, you can check for RAM access. RAM accesses are slow and easy to detect (I'm sure there even are hardware counters for that kind of thing on modern CPUs).

So unless you can get any kind of hard evidence that would even shed the base of the idea of a doubt about what rdrand is doing: this is pure FUD.

Finding out how rdrand is truly implemented is hard, but if it's truly the evil instruction of doom that sends images from your webcam to the NSA then it should be trivial to prove it's not behaving as it should.

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

#46

Post by solarexplorer »

zamalek wrote: post #28
tspiteri wrote: post #13

Please do not submit professional troll articles.

Agreed. This article is very one-sided, and after posting a calmly worded comment regarding Linus's standpoint[1] on his attitude, it was deleted. The article is simply link bait and is not professional journalism. That being said, I have more confidence in Linus's knowledge regarding /dev/random. Mostly because XOR in this context is secure: 1. XOR is an incredibly powerful encryption algorithm (not primitive); one…

The argument is that RDRAND may have access to the previously generated OTP. If that is true, a malicious RDRAND can cancel out any randomness from that OTP. In that case the "incredibly powerful encryption algorithm" XOR can be tricked to generate a stream of zeros, shakespeares complete works, or whatever you like.

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

#47

Post by anon1385 »

icecreampain wrote: post #11
antocv wrote: post #8

Earlier quoted context omitted.

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 w…

Using [only] Windows should automatically disqualify one from giving and security related advice. At least Linux and BSD source is viewable by people. Lots of people.

The same lots of people that immediately noticed when Debian shipped a broken openssl? Or the ones that didn't notice at all for years until somebody noticed identical certs showing up in the wild?

https://en.wikipedia.org/wiki/Random_number_generator_attack...

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

#48

Post by noselasd »

makomk wrote: post #31
jacquesm wrote: post #16

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. Even if rdrand is 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…

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…

> question and XOR the output of RDRAND with the randomness from the other entropy sources before returning it.

How is that easy ? No, predicting or detecting that the returned value of your assembly instruction will later be xor'ed by some other value, in all it's machine code variants that different versions of gcc will produce, is not easy.

It is theoretically possible if you have access to the CPU design and can modify it, but even then it is very non-trivial, if even doable in the general case.

There are several free CPUs around you can instantiate on an FPGA and boot linux on - if someone makes a proof-of-concept rdrand() on one of these that can detect the future bit operations on the value(even when it's moved to another register or to/from main memory) and cancel out that bit operation - then I'll believe it's possible.

Until then, I'm more(more compared to not at all is still very little) worried that:

* the chip (whose part number google knows nothing about) in my dsl modem have a backdoor and being able to mirror all its traffic

* that the baseband chip in my HTC has the same ability - in addition to the know ability of being able to report its gps location without informing me

* that the NSA probably still can read my gmail mail

* that my raspberry pi SoC can contain an unknown component that dumps it's memory out the ethernet card

* that the latest iPhone perhaps complies nicely with the 3GPP TS 33.108 spec.

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

#49

Post by mcherm »

noselasd wrote: post #48
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…

> question and XOR the output of RDRAND with the randomness from the other entropy sources before returning it. How is that easy ? No, predicting or detecting that the returned value of your assembly instruction will later be xor'ed by some other value, in all it's machine code variants that different versions of gcc will produce, is not easy. It is theoretically possible if you have access to the CPU design and can…

Did you read the article? They explained why an implementation of RDRAND as "XOR together the contents of all registers and return it" would result in removing nearly all of the entropy in the state vector. And it proposed a simple solution: modify the code so that the hardware entropy is mixed in earlier in the process (in which case it WOULD require the prodigious feats you are talking about).

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

#50

Post by laumars »

icecreampain wrote: post #9

If 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 intere…

I assume your post was intended to be ironic?

> "Write an operating system that is used by millions of people and powers a large part of the Internet (together with BSD and friends)."

Linux wrote a kernel, not the full OS user land. What's more, most of the code in Linux (the kernel) isn't actually written by him - these days he's job is more that of a maintainer. Not that I'm trying to undermine his achievements - just pointing out that you're making the same exaggerated arguments as the blogger you're condemning.

> " Stop writing bullet lists about people."

You mean like the bullet list you've just written?

> "Stop trying to attract hits to your tech blog and create something of use to the human species."

Again, like you've just done. Let me explain with a little code:

    ($potkettleblack = $_) =~ s/tech blog/forums/;
> "Criticize what people say, not how they say it."

Which would be fine if the whole premise of your argument is complaining about not what the blog said by how the blogger said it.

Don't get me wrong, I have a lot of respect for Torvalds, but your comments were -at best- hypocritical. Though I'd say they were much worse than that as at least the blog in question added some content to compliment their clickbait headline. You've not even touched on the real subject matter of this topic.

Post reply on HN