4 ms·
I see a few people mentioning applications of this in cryptography and I feel that this is harmful. You do not need exotic hardware to collect entropy to gener
by marshray 15y ago
I see a few people mentioning applications of this in cryptography and I feel that this is harmful.
You do not need exotic hardware to collect entropy to generate crypto keys. You need a correctly designed cryptographically secure PRNG which has had time to accumulate 100 or so bits of entropy (i.e., unknowability to the attacker). It's nice if it can be freshened every now and then with more entropy, but that really only should make a difference if you lose a backup tape and by some miracle the private key wasn't on there already. After it's warmed up, it should never need to block due to 'depleted entropy'. No one has ever broken such a CSPRNG. This is how the OpenSSL, OpenBSD, and FreeBSD /dev/randoms work.
On the other hand, what does tend to get broken regularly are overcomplicated and overengineered RNGs like this beast.
The one on the new Intel chips is handy, but it's largely overkill. We only need 100 bits now and then, not a steady rate at Gb/s (which can shut off abruptly when an attacker sharing your cloud hardware node decides to starve you of them). It's also not something that we can review for backdoors, so we should be reluctant to use it as the sole source of entropy.
A quantum vacuum random server is great like the way an internet-connected coffee pot is great. Fun, but not useful in production.
- tptacek 15y agoOne wouldn't want to give the impression that CSPRNG design is a solved problem, but I think you're right: exotic "true random" entropy sources definitely don't target the real challenges.
- marshray 15y agoI believe it is largely a solved problem. Or at least the unsolved parts are reduced to a single problem: entropy input estimation.
- JoachimSchipper 15y agoAre you aware of any instances of the OS /dev/Xrandom failing in an exploitable way, assuming proper initialization? I'm sure that people still mess up, but there are a lot of problems that are solved in that sense.
- tptacek 15y agoThere's a well-known and very good Black Hat talk from I think 2007 that attacked cold-start entropy on embedded devices, but you could rephrase that as an entropy estimation problem.
- acqq 15y agoOn Linux, the need for hardware sources became more visible because of this: "/dev/random vs /dev/urandom" http://www.onkarjoshi.com/blog/191/device-dev-random-vs-urandom/ http://www.onkarjoshi.com/blog/191/device-dev-random-vs-uran... /dev/random is hardware entropy dependent, and if application users use it too much (and we all know that many application developers don't do what's minimal stress for hardware or what's optimal "I just make it fast, it works for me"), every such application can block too often. Especially servers are problematic because you can't accumulate the entropy by measuring keyboard or whatever. That's why Intel made RdRand. And their competitors made some similar solutions even before that. Good detailed discussion also on: http://en.wikipedia.org/wiki//dev/random http://en.wikipedia.org/wiki//dev/random In short, hardware RNG in the CPU is a very good thing. Of course, whoever doesn't need cryptographically secure randomness should anyway just use plain old pure software pseudorandom number generator: http://en.wikipedia.org/wiki/Pseudorandom_number_generator http://en.wikipedia.org/wiki/Pseudorandom_number_generator
- marshray 15y agoln -sf /dev/urandom /dev/random OpenSSL, OpenBSD, and FreeBSD agree with me.