* Mike Stay <metaweta@gmail.com> [Feb 17. 2012 19:25]:
[...]
Boxen running in a data center with only a solid-state hard drive (perfectly predictable seek times) and a network card where traffic is carefully distributed and very predictable have real troubles getting enough randomness.
Oh, I see. Get an FPGA board, implement a (deterministic) random number generator (with _very_ long period), and XOR in entropy from several independent noise sources (on that FPGA board, say 5 such at $3 each ("enterprise solution")). Should at the _very_ least give you, one 1024 (super-OMG!-)random bitstring per second. Given the (enormous) possible parallelism that an FPGA offers we may just run many deterministic generators (all of different periods, but the exact instance and state of the generator not accessible), XOR (an (entropy-) random choice of) them to get as much random bits per sec as the bus can transfer. Problem solved? No, people will not use it because they do not realize how bloody important the "random" part is.
Btw. /dev/random and /dev/urandom (under Linux) should do the trick already.
In situations like the one above, the server would either block on dev/random or be vulnerable because all the entropy has been depleted.
Yes, the "real" one of those two (can never remember which) does block if no usable entropy is available.
-- Mike Stay - metaweta@gmail.com http://www.cs.auckland.ac.nz/~mike http://reperiendi.wordpress.com
Does anyone know how much RSA enforces the two primes to be of similar size? I always thought that one should rather use a supersize key (say, 16k bits) and allow the primes to be of vastly different size (say, requiring the smaller one just being >=3000 bits). No collisions then! (Oh, wait, I assumed the "random" part non-ignored...)