Re: [Caml-list] Hashtbl and security

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

Am Montag, den 02.01.2012, 00:24 +0100 schrieb oliver:
> > 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 also might not be good enough for some certain areas.
> 
> val Hashtbl.HashedType.hash: t -> int
> 
> allows at least providing your own hashing.function,
> but that function then must be sophisticated enough
> to provide some dynamic re-seeding.

It does not allow this. Because of this, the new Hashtbl (only in svn so
far) has the additional seed parameter.

> > 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.
> 
> That's already planned and even implemented, as was mentioned in this thread.
> So urging for a new official release would make sense.

Not exactly. Xavier mentioned that he withdrew the automatic seeding. If
nothing changes, you will have to provide a seed parameter to every
Hashtbl.create, coming from a rng of your taste. This is what I don't
like - programmers will in most cases simply ignore this possibility,
and I predict it will even be ignored when there are strong indications
for security threats. Also, there is no good access to rng's. Random is
not designed with security in mind. The OS typically provides a
generator which is much better (like /dev/random), but there is no
uniform interface to it that would make it easy to use it.

My concern is that the security options will simply be ignored unless
the standard library includes some half-way secure defaults.
 
> > What I could imagine is a module Sys.Security where all security
> > features are accessible and configurable, e.g.
> 
> I doubt that this makes sense.
> Nearly anything that can be programmed can become a security
> issue, if done wrong; especially things done on the
> operating system level (like Unix module) could become
> a security issue, if things are handled without care.

Thanks for your argumentative help - by being ignorant you prove my
thesis that typical programmers won't do anything by themselves. The
world is so much trouble, better put the head into the sand, and hope
the attacker won't pick you. (Well, sorry, maybe a bit too harsh, but I
hope you get my point that it is no excuse that also other security
issues may exist).

The dangerous thing here is that it is not always apparent which hash
tables are exposed in areas with security demands. So, it would be good
if all hash tables had some basic protection built-in.

> A mandatory (not optional) hash-function-parameter
> that must be passed (plus some default hash functions
> with elaborated documentation on the properties of those)
> would make more sense to me.

The seed is so far optional. Sure, requiring it mandatorily would ensure
it is passed, but I guess programmers would just become used to the
idiom "Hashtbl.create ~seed:0 ()". I'd like to rather see that at least
a default seed is automatically chosen at program startup (there might
even be better schemes like selecting a new default seed after every GC
cycle or so).

> Putting things that need tp be part of the Hash-module
> aside into a Sys.security-module makes these things less
> apparent to the programmer who just wants to use hashes,
> and don't thinks about using hashes might be a security problem.

If done right, this won't be a problem anymore for the typical user (who
e.g. programs a web page, and where nobody would spend millions to hack
it). Of course, if you want to run a trust center, you'll have higher
demands, but I guess you'll check then your code base thoroughly for
issues, and won't forget to pass seed parameters wherever needed.

Gerd

> So, this solution IMHO would be counterproductive
> and non-intuitive.
> 
> 
> Ciao,
>    Oliver
> 
> -- 
> 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
> 
>