81–90 of 100 posts
Earlier quoted context omitted.
I agree. Try searching for the title on gmane.org
Here's the list on gmane: http://news.gmane.org/gmane.comp.security.cryptography.rando... Not sure how to link a particular article in that view. The 'direct link' sends you to an article-only page. But the message by the OP appears as the third top-level thread in that view.
You get to that by clicking on the subject in the bottom frame.
Another class of randomness is that which is used to randomize the layout of shared libraries, stacks, etc. --- address space layout randomization (ALSR). If someone is able to guess the randomness used by ASLR, then they will be able to more easily exploit stack overrun attacks, since they won't need to guess where the stack is, and where various bits of executable segments might end up in the address space's layout.
Another case of randomness is to create crypto keys; either long-term keys such as RSA/DSA keys, or symmetric session keys. If someone screws this up, that's when the "bad guy" (in this case, people are worried about the NSA being the bad guy) can get access to encrypted information.
It is only the first two use cases where we use RDRAND without doing any further post-processing. These are cases where the failure of the RNG is not catastrophic, and/or performance is extremely critical.
We do not use RDRAND without first mixing it with other bits of randomness gather in the system for anything that is emitted via /dev/random or /dev/urandom, because we know that this is used for session keys and for long-term RSA/DSA keys.
The bigger problem, and it's one that we worry a huge amount about it, is the embedded ARM use cases which do not have RDRAND, and for which there is precious little randomness available when the system is first initialized --- and oh, did I mention that this is when long-term secrets such as SSH and x.509 keys tend to be generated in things like printers and embedded/mobile devices and when they are first unwrapped and plugged in, when the amount of entropy gathered by the entropy pool is usually close to zero? What we desperately need to do is to require that all such devices have a hardware random number generator --- but the problem is that there are product managers who are trying to shave fractions of a penny off of the BOM cost, and those folks are clueless about the difference between cost and value as far as high-quality random number generators are concerned.
What if the RNG has been compromised by the NSA? Well, that's where you need to mix in other sources of randomness into the entropy pool. The password used by the user when he or she first logs into an android device, for example. Screen digitizer input from the user while they are first going through the setup process. In the case of a consumer grade wireless router, it could sniff the network for a while and use packet inter-arrival times and mix that into the entropy pool. Yes, someone who is on the home network at that time will know those numbers, but hopefully someone who is in a position to spy on those numbers, isn't also going to have access at the same time the super-secret NSA key used to gimmick the RDRAND instruction (assuming that is gimmicked, which is effectively impossible for us to prove or disprove.) But then again, your wireless router isn't going to have access to unencrypted plaintext which is critical --- if you're sending anything out your wireless network without first encrypting it first, I would hope that you would consider it completely bare and exposed!
If you are super paranoid, you'll need to find a hardware random generator which you've built yourself --- and hopefully you are competent enough to actually build a real HWRNG, and not something which is sampling 60 Hz hum (or 50 Hz hum if you are in Europe :-), and mix that into the entropy pool as well. In that case, even if the Intel RDRAND is compromised six ways from Sunday, the NSA won't have access to the output from the HWRNG --- and if it turns out you were incompetent and your HWRNG is bogus, at least RDRAND is also getting mixed into the entropy pool.
And if I were in China, I'd use a hardware chip built in China for the RNG, and combine that with an Intel chip. That way even if the HWRNG chip is compromised by the MSS, and even if RDRAND is compromised by the NSA, the combination is hopefully stronger since presumably (hopefully!) it's unlikely that the MSS and the NSA are collaborating with each other at that deep a level. Ultimately, of course, if you don't trust Intel, you don't trust the silicon fab, etc., then you'll have to build your own computer from scratch, write your own compiler from scratch, etc.
(MIT CS undergrads used to have all of that knowledge, starting with building a computer out of TTL chips and how to build a Scheme interpreter from machine code, etc. But not any more, alas. Now they learn Python and it's assumed that it's impossible to understand the entire software stack, let alone the entire hardware stack, so you don't even try to teach it. But that's another rant....)
The annoying thing is that the Linux RNG is really limiting without something like RdRand. It used to be that most drivers contributed to the randomness pool, so it seldom ran short. It used to be that you could configure the size of the pool, so if you were running short you could make it larger. But then it was discovered that the pool resizing had a locally exploitable vulnerability so it was removed, leaving it a…
Apparently, for some "security experts" it's damned if you do, damned if you don't If you don't use RdRand then you have few sources of "true" randomness, hence, your RNG is predictable, manipulable and you're an idiot and a 5 year old can break your crypto If you use RdRand then "blah blah blah this is opaque", hence, your RNG is predictable, manipulable and you're an idiot and a 5 year old can break your crypto Per…
The best approach to have is IMHO here: http://en.wikipedia.org/wiki//dev/random Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator[5] in which they describe several weaknesses. Perhaps the most severe issue they report is with embedded or Live CD systems such as routers and diskless clients, for which the bootup state is predictable and the ava…
There are several different ways in which randomness is used in the kernel. One general class of randomness is things like randomizing the sequence numbers and port numbers of new network connections. If you can predict the result of this randomness, it becomes easier to carry out attacks such as hijacking a TCP connection. (Note that if the active attacker controls the path between the source and the destination, th…
This is the first that I heard that he had resigned over the RDRAND getting used directly, and I track LKML discussions, especially on topics such as file systems and random number generators, pretty closely. What I suspect happened is someone pushed this patch to Linus without going through him, and he got annoyed and just stopped work.
What happened about 18 months ago was some researchers approached us about the deficiencies hey found documented at http://factorable.net. It when then that I discovered that Matt Mackall had resigned (although the MAINTINERS file still listed him as the maintainer --- normally when people resign in a huff they send a patch to remove themselves from the MAINTAINERS file). So at that point, I took over the maintenance duties.
It was at that point that I changed things so that RDRAND was only used directly for non-critical items, and started addressing how to gather as much entropy as possible for those platforms which do not have RDRAND --- which in fact was the bigger deal, and right now, probably the far greater set of problems.
That leads me to another important point --- don't get too focused on RDRAND. Yes, it's something we need to be concerned about, but there are many different ways people can screw up security, and not all of them require active collusion with the NSA.
For example, there are several years worth of HP printers where it's possible to push an unsigned firmware load to said printers over the network, at which point said printer could be sending copies of everything sent to it back to the NSA or the FBI. This would require no collusion between HP and the US government --- just the incompetence of HP firmware engineers. Could the NSA or the FBI be exploiting such a hole? I'd actually argue that given the FBI's mission, it would be malpractice for them not to develop such a trojan'ed firmware load. Hopefully they would only be using it after getting a search warrant, but if such a hole exists, and their mission is to get the bad guys, subject to US laws and the US constitution, I have no problem with them trying to create such exploits. Of course, I do blame HP for making it be possible to create such an exploit in the first place, and so we need to hold manufacturers accountable.
So we need to be vigilant, and worry about auditing all of the potential attack surfaces, and not just worry about one particular place where Intel might have colluded with the NSA. There are lots of other places where collusion is not required; just simple carelessness and incompetence by software engineers....
The best approach to have is IMHO here: http://en.wikipedia.org/wiki//dev/random Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator[5] in which they describe several weaknesses. Perhaps the most severe issue they report is with embedded or Live CD systems such as routers and diskless clients, for which the bootup state is predictable and the ava…
Yes - for example this is done by /etc/init.d/urandom on Debian and Ubuntu systems.
I see Ted Ts'o commented too, and as I understand, having RdRand is still much better compared to having the platforms without it. There's a lot more to care about than is RdRand "perfect" and once you have something like RdRand you can use it safely enough, compared to not having anything.
Earlier quoted context omitted.
Apparently, for some "security experts" it's damned if you do, damned if you don't If you don't use RdRand then you have few sources of "true" randomness, hence, your RNG is predictable, manipulable and you're an idiot and a 5 year old can break your crypto If you use RdRand then "blah blah blah this is opaque", hence, your RNG is predictable, manipulable and you're an idiot and a 5 year old can break your crypto Per…
What happens if I tune my DVB card in, sample /dev/video0 or whatever it is now and use that to add entropy? Is that even possible?
There are several different ways in which randomness is used in the kernel. One general class of randomness is things like randomizing the sequence numbers and port numbers of new network connections. If you can predict the result of this randomness, it becomes easier to carry out attacks such as hijacking a TCP connection. (Note that if the active attacker controls the path between the source and the destination, th…
What do you propose as a low cost solution? I've seen some interesting suggestions, such as having a small fish bowl or tube or tank, having air pumped into the bottom, and sampling the patterns of bubbles with some CV solution. Sounds geeky, would make for a nice decoration on one's table, but building it seems like quite a job.
Earlier quoted context omitted.
Yes - for example this is done by /etc/init.d/urandom on Debian and Ubuntu systems.
My question was for /dev/random. The main problem RdRand solves is quantity: obtaining a lot of random bits per second. Even if they were produced in a way that somebody knows possible weaknesses, mixing them with something cryptographically strong where we control the seed we'd preserve quite a high throughput. I know that there is /dev/urandom which can often be good enough, but I know that too much applications in…
The seed that is saved at shutdown and reloaded at startup will alter the internal state of the /dev/random pool, but it won't add to the entropy estimate (which makes sense). This means that the output will be more robust, but it could still block waiting for "real" entropy.