From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q01L4Bn9012578 for ; Sun, 1 Jan 2012 22:04:11 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAHTJAE/U4xEJkGdsb2JhbABDggWDCqdIIgEBAQEJCQ0HFAMigXIBAQUjBFIQCxgCAiYCAlcGEwkSh2EGowOQXoEviUqBFgSNGo03jGY X-IronPort-AV: E=Sophos;i="4.71,441,1320620400"; d="scan'208";a="125220099" Received: from moutng.kundenserver.de ([212.227.17.9]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Jan 2012 22:04:05 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-218-084.pools.arcor-ip.net [94.219.218.84]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0M6VWV-1SfTzC0b5H-00yU0n; Sun, 01 Jan 2012 22:04:05 +0100 Received: from [192.168.178.30] (546BF816.cm-12-4d.dynamic.ziggo.nl [84.107.248.22]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id B5D19C00C7; Sun, 1 Jan 2012 22:04:04 +0100 (CET) From: Gerd Stolpmann To: Xavier Leroy Cc: caml-list@inria.fr In-Reply-To: <4F0097E6.2090701@inria.fr> References: <1325263446.5036.104.camel@samsung> <4EFDEF92.3010204@inria.fr> <20120101125212.GB12851@annexia.org> <4F0097E6.2090701@inria.fr> Content-Type: text/plain; charset="UTF-8" Date: Sun, 01 Jan 2012 22:04:03 +0100 Message-ID: <1325451843.5036.165.camel@samsung> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:49dm6jDkv8yR4jL8LA4y0ac/EZW531SolPYjkBqvFtd MgfHSJLxxdz7YsMRKVTe854ssWbwwi3VubRa9OHo4htbbszWsv TdZJqCEk58h00cJtKVC1BKux4QhznTBMmZendrQoi68TrA32lw 2fUQjcOLUFmwAJCB/F9fyXg/ac2u4IWN9q4m5wG4nCbR7Oe3sR Ueyco/O4CNloApA6LbAxxxaKSIfJHHUH3ilxaERf810ZnUviZO msM/TmmKxmpcGdRtV5DVPOtAYa/0YUyFFWoQxKIcB/ET04nOD/ CQzMViTU5NDX77zwEV7iQYPabmpmApVV6Pj1xBHFH4MlkVu5Xy qAj6Z0lmfL+DOokww3mOIY8qtvrw2hQ8G3doY/KB7 Subject: Re: [Caml-list] Hashtbl and security 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 gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------