Re: [Caml-list] Hashtbl and security

[Gerd Stolpmann <info@gerd-stolpmann.de>]

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
------------------------------------------------------------