Am Sonntag, den 01.01.2012, 18:29 +0100 schrieb Xavier Leroy: > On 01/01/2012 01:52 PM, Richard W.M. Jones wrote: > > On Fri, Dec 30, 2011 at 06:06:26PM +0100, Xavier Leroy wrote: > >> Indeed. The optional "seed" parameter to Hashtbl.create does exactly > >> this in the new implementation of Hashtbl (the one based on Murmur3). > > > > It may be worth noting that Perl solved this problem (back in 2003) by > > unconditionally using a seed which is a global set to a random number > > during interpreter initialization. > > That's how my initial reimplementation of Hashtbl worked, using the > Random module to produce seeds, but I was told (correctly) that in > security-sensitive applications it's better to leave the generation of > random numbers under control of the programmer. For some applications > Random.self_init might be good enough and for others stronger > randomness is needed. > > Of course, you can trivially emulate Perl's behavior using the new > Hashtbl implementation + the Random module.
I understand it very well that adding support for cryptographically secure random numbers to core Ocaml is a challenge. There is no POSIX API, and /dev/random is, although widely available, still non-standard. And it is certainly true that there are various levels of security, and for some purposes the programmer should be free to install even better generators. Nevertheless, Ocaml is now widely used in environments where a certain minimum of security is demanded, and I think Ocaml should provide this minimum at least, and use it for things like an automatically chosen seed for hash tables. My argument is: Even providing a half solution is in this area better than leaving the unwary programmer completely alone. Because in the latter case, nothing will be done to address the problems, and apps would be easier to attack. What I could imagine is a module Sys.Security where all security features are accessible and configurable, e.g. val set_default_seed : int -> unit val fill_randomly : [`Fast|`Safe] -> string -> unit val set_fill_randomly : ([`Fast|`Safe] -> string -> unit) -> unit The configure script could check what is available on the system. The `Fast mode is guaranteed to always exist, and would essentially be /dev/urandom if available and otherwise Random-based. The `Safe mode would require /dev/random (or comparable), and fail otherwise. (See Wikipedia http://en.wikipedia.org/wiki/dev/random for a list of OS, and for weaknesses.) The user can override the RNG if the defaults are not ok, or if exact control is required. Of course, one could criticize such an interface in various ways. For example, it only allows a global security profile, and not different profiles for different parts of the program. Also, the distinction between a fast and a safe generator sounds a bit arbitrary. My response is simply: this is the price for the broad effect, and IMHO this counts more than having a more elaborated but also more difficult solution, or lots of user-specific solutions (as we would have to find today). Gerd -- ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany g...@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ -- 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
