Friday, September 13, 2013

Petition to remove RdRand from /dev/random in Linux Kernel

Someone started a petition to remove RdRand from the Linux random number generator (RNG) /dev/random.

The argument are that the code uses the hardware RNG from the Intels Ivy-Bridge CPUs (RdRand instruction) if present. It is assumed that there is a NSA Backdoor in Intels RNG. So he started this petition to get the specific code removed from the Kernel. Well the arguments (which I will explain later) are nonsense (well maybe not totally).

Linus Torvalds responds to this petition shows what is mentioned in “Team Geek” when they talk about the “Linux kernel community” (page 87):
Guys, go read drivers/char/random.c. Then, learn about cryptography. Finally, come back here and admit to the world that you were wrong. Short answer: we actually know what we are doing. You don't. Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of RdRand actually improves the quality of the random numbers you get from /dev/random. Really short answer: you're ignorant. (Linus Torvalds)

There is a German saying from Max Frisch which I really like:
Man sollte die Wahrheit dem anderen wie einen Mantel hinhalten, dass er hineinschl├╝pfen kann – nicht wie ein nasses Tuch um den Kopf schlagen.

(rough translation: you should help people to understand the truth and not just throw it around their head like a wet rag)

Linus often (always?) uses the wet rag method.

Now to the arguments:
Actually Tayler Hornby did read random.c and pasted it with some comments on pastebin and explains his arguments in the comments at the end of the file.

He says that even though different sources for the random number are used they are XORed together. The RdRand instruction could be smart enough to produce purposely a number which is the inverse of the bits it is going to be XORed with so the result of the XOR operation will be zero.

Well maybe RdRand is smart enough to find out that it is called from the Linux Kernel then it must still find the other bits its result will be XORed with to find out which bits it must return.

Brad Peabody left a nice comment to this:
The point being made by Taylor is that rdrand could be "smart" enough to understand the state of the rest of the random number generator (which would require reading various state information from a combination of CPU cache, registers or memory) and use that to intentionally spoil the output of the function. This is a no-issue. If that is the case and the CPU is being tampered with in such a way as to perform this kind of sophisticated attack, then why does one xor even matter? As he points out already: "This is the CPU, remember. It can pretty much do anything it wants." Changing the number generation to exclude rdrand isn't going to improve security.

I think this is the answer that Linus should have given to be really helpful.

And Theodore Ts'o (the author of random.c) comment to the petition is much smarter (than Linus comment):

I thought of this issue over a year ago. See:
To Dale's question, if the microcode can figure out where the entropy pool is and figure out what it's being XOR'ed with and adjust accordingly, you're toast anyway. No matter what you can do, if the adversary has control of the cpu microcode at that level, the adversary can just modify the returned entropy value in memory.
Realistically, there are real limits to what you can do in the cpu microcode, especially if you are trying to remain covert and be undetectable by people who are testing the CPU, both inside Intel and people who are doing low-level OS work. You need to keep modifications which subvert security software to the bare minimum, or else someone will eventually notice.

Tuesday, September 10, 2013

Practical Anonymity by Peter Loshin, Syngress

The content of the book can be best described with the following statement from the author: „The subject of this book: how to connect to the Internet with the confidence that someone listening in to your connection won't be able to figure out what you are doing (or at least make it very difficult)“

This book is all about Tor. From why people use Tor, how to get Tor or Tails, how too use Tor, how it works and what you shouldn't do when you use Tor.

Peter doesn't go too much into details. I thinks it's just enough information to get an understanding how the reader can archive anonymity and what tools (and how) to use. The target audience are novice users who don't have much experience with Tor. He presents Links to websites with detailed information for the interested reader.

He explains how Tor works and how Tor can protect your anonymity. He describes the Tor Browser Bundle and Tails. Further he explains what Tor Relays and Tor hidden services are and how to step them up and configure them.

At the end of the book he shows how to use E-Mail anonymously (with Tor).

When you finished this book you know a lot about Tor. Certainly not all the details, but you have heard about it and the reader knows where he can get further information.

In my opinion this book is really good and is easy to read. I hope that many people will read the book and start using Tor.

You can find further information here.