Gerd Stolpmann writes: > The Random module is definitely not good enough (e.g. if you > know when the program was started like for a cgi, and the cgi reveals > information it should better not like the pid, the Random seed is made > from less than 10 unpredictable bits, and on some systems even 0 bits).
Dario Teixeira adds: > I think the problem may be in finding a good source of randomness > that is common across all OSes. In Unixland this problem has > largely been solved: pretty much everyone supports /dev/random and > /dev/urandom. Windows does things differently, however. David Allsopp adds: > Does the source of randomness have to be common? The decision to use > a random seed doesn't need to be limited by a problem getting a good > cryptographically secure generator on a given OS - you'd simply > document that the implementation on that particular OS doesn't seed > with a good PRNG and await a patch from someone who may care in the > future, but at least the philosophy behind the decision is correct! We are also thinking of strengthening Random.self_init, for instance by using /dev/urandom when available. This said, for randomizing hashtables or other data structures, we do *not* need a cryptographically-strong PRNG: we're not generating an RSA key pair or some other situation where cryptographic quality is required; we're just making a mild DOS attack impractical. (Obligatory advertisement: if you're in need of cryptographically-strong random data, http://forge.ocamlcore.org/projects/cryptokit/ is what you need.) - Xavier Leroy -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
