D. J. Bernstein wrote: [...]
There are of course more defenses that one can add to provide resilience against more severe randomness deficiencies: one can start with more random bits and hash them down to 256 bits; use repeated RDTSC calls as auxiliary randomness input; etc. These details have essentially nothing to do with the choice of cryptographic primitive, and the whole point of /dev/urandom is to centralize these details and get them right rather than having everybody reimplement them badly. It would be interesting to understand how /dev/urandom failed for the repeated RSA primes---I'm presuming here that /dev/urandom was in fact the main culprit.
Isn't /dev/urandom BY DEFINITION of limited true entropy? True entropy collection may take time (and is inescapably based on environmental assumptions) while /dev/urandom is defined as non-blocking. No matter the theoretical properties of the (deterministic) PRNG component of /dev/urandom, they can not expand *true* entropy.
And this is so, no matter the amount of details you delegate to reputed security software developers.
Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
