4 ms·
Maybe for the rare cases you might need an extremely high rate of random numbers? I'm trying to think of applications where you need both the security and high
by darkmighty 11y ago
Maybe for the rare cases you might need an extremely high rate of random numbers? I'm trying to think of applications where you need both the security and high rate but it's quite hard indeed (simulations and things like procedural texture/art gen are high rate but non-secure, while secure things are all low rate).
- tptacek 11y agoNo. It does not matter at which rate you're pulling from /dev/urandom. The first byte you get is as secure as the zillionth.
- darkmighty 11y agoI know it doesn't matter security-wise, but the hardware still has to do the (crypto) work, whereas hardware TRNGs can get it for "free": the price per bit of entropy can be smaller for a well designed TRNG.
- tptacek 11y agoThis strikes me as very unlikely; the work that a software DRBG does is very cheap, and probably far cheaper than IO to pull bits off a hardware RNG.
- darkmighty 11y agohttp://www.nature.com/nphoton/journal/v4/n1/abs/nphoton.2009.235.html http://www.nature.com/nphoton/journal/v4/n1/abs/nphoton.2009... This device apparently generates reliably a 300 Gbps random stream. Not easy/cheap to do with DRBGs. But as I said, I have no idea of any application where this would be required.
- tptacek 11y agoAgain: I'm simply saying that I/O is probably significantly slower than a software DRBG, no matter how fast the peripheral is internally.
- oconnor663 11y agoAn SSL proxy server for a high traffic website is a good example of something that needs a lot of secure random numbers, I think.
- oconnor663 11y agoGot some downvotes for the parent, and I'd like to be corrected. Don't IV's and nonces for AES-CBC and AES-CTR require 16-32 random bytes, among other things?