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

31–40 of 77 posts

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

#31

Post by makomk »

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 implementation except to the attacker.

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. The two XORs cancel out, and this is completely undetectable because there's no way to distinguish between a true random bitstream, a good PRNG, and a good PRNG XORed with data you provided based on the bits themselves.

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

#32

Post by jedbrown »

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…

get_random_bytes() documentation:

    This function is the exported kernel interface.  It returns some
    number of good random numbers, suitable for key generation, seeding
    TCP sequence numbers, etc.
Here is the accepted commit that makes get_random_bytes() use RDRAND directly:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

Note that this was version 3 of that patch. Versions 1 and 2 also took control of /dev/urandom. Here is v2:

http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117...

A year later, Ted Ts'o made get_random_bytes() go through the usual entropy pool and added get_random_bytes_arch() for a consumer that doesn't want to go through the entropy pool. (The core kernel does not currently use get_random_bytes_arch() anywhere.)

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

Note that the heated discussion came before v3 of Anvin's patch, and thus /dev/urandom was included. Matt's objections were perhaps not expressed very clearly, but Linus was pretty cavalier in overruling Matt Mackall (the /dev/random maintainer at that time) and I think his retort to George Spelvin's very rational objection was unreasonable:

http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117...

I find it scary that these commits made it as far as they did. Note also that on the day of the leaks (ironic timing), Ts'o had to shoot down a RedHat engineer proposing to once again make get_random_bytes() bypass the kernel entropy pool.

https://lkml.org/lkml/2013/9/5/212

As for other locations, the point is to be undetectable while deployed at massive scale. Keyloggers and active backdoors are much higher risk. Great for a targeted investigation, but terrible for untargeted passive surveillance.

https://plus.google.com/u/0/117091380454742934025/posts/XeAp...

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

#33

Post by iSnow »

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…

>The author of the article is just another "tech blogger"

So ridiculing him instead attacking his arguments is A-OK but he has to keep silent because Thorwalds is a great coder?

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

#34

Post by Perseids »

willvarfar wrote: post #27
makomk wrote: post #23

Earlier quoted context omitted.

Mucking with RDRAND can easily be done in such a way that it's provably impossible to detect any differences in behaviour. It's much harder to guarantee that if you start mucking with buffers in memory, since there are so many clever ways a developer could check their work and catch you out.

How's the provably impossible to detect bit work again? Surely it'd fail a Chi Square test on reruns with the same input? The attack can't use external input e.g. clock because the NSA can't correlate generating the random number with seeing it in flight.

Why should the CPU not have an internal counter that is backed up in flash memory between reboots? 128bit would be enough, with the highest bits set to the processor serial number. Using this counter in AES-CTR mode – i.e. encrypt the counter with the secret key to generate the pseudo random data – the NSA could reconstruct the internal CPU state from a single block (16 bytes) of random data. As many random data is published verbatim, for example as nonces, getting such a block should not be a problem.

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

#35

Post by [deleted] »

willvarfar wrote: post #27
makomk wrote: post #23

Earlier quoted context omitted.

Mucking with RDRAND can easily be done in such a way that it's provably impossible to detect any differences in behaviour. It's much harder to guarantee that if you start mucking with buffers in memory, since there are so many clever ways a developer could check their work and catch you out.

How's the provably impossible to detect bit work again? Surely it'd fail a Chi Square test on reruns with the same input? The attack can't use external input e.g. clock because the NSA can't correlate generating the random number with seeing it in flight.

[deleted]

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

#36

Post by zamalek »

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…

The author makes an argument that is somehow both adhom and slippery slope. By pointing out something that everyone knows (Torvalds is rude, which not necessarily a bad thing depending on who you ask) he adds weight to his second argument about /dev/random being insecure (which is complete bollocks). I christen this logical fallacy the "Ducklinism".

And I have to agree with you about his obvious lack of expertise in the department. Where he fails to make a compelling article is not his lack of expertise, rather the lack of interviewing many people who do have that expertise.

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

#37

Post by makomk »

Perseids wrote: post #34
willvarfar wrote: post #27

Earlier quoted context omitted.

How's the provably impossible to detect bit work again? Surely it'd fail a Chi Square test on reruns with the same input? The attack can't use external input e.g. clock because the NSA can't correlate generating the random number with seeing it in flight.

Why should the CPU not have an internal counter that is backed up in flash memory between reboots? 128bit would be enough, with the highest bits set to the processor serial number. Using this counter in AES-CTR mode – i.e. encrypt the counter with the secret key to generate the pseudo random data – the NSA could reconstruct the internal CPU state from a single block (16 bytes) of random data. As many random data is p…

Yeah, or if the onboard flash memory is too difficult to implement, they could even just initialise the lower bits of the counter from the real hardware RNG every boot. Either of these options would be statistically indistinguishable from true randomness unless you knew the key.

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

#38

Post by jgrahamc »

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…

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

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

#39

Post by Perseids »

mbq wrote: post #26

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 "consumer computing" like…

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...

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

#40

Post by pekk »

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…

> 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.

This isn't cryptography, it's politics. The 'taint' is ideological.

Post reply on HN