From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q04LqUV8019706
	for <caml-list@sympa-roc.inria.fr>; Wed, 4 Jan 2012 22:52:30 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksCAGrJBE/AbSoIe2dsb2JhbABDggWDCqddIgEBFiYEIYFyAQEEASNWEAsJDwICJgICFBgxiA0CpAGRMBOBHIlKM2MEjUiHO5I2
X-IronPort-AV: E=Sophos;i="4.71,458,1320620400"; 
   d="scan'208";a="137878815"
Received: from einhorn.in-berlin.de ([192.109.42.8])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jan 2012 22:52:25 +0100
X-Envelope-From: oliver@first.in-berlin.de
Received: from first (e178001063.adsl.alicedsl.de [85.178.1.63])
	(authenticated bits=0)
	by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id q04LqN5j030043
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 4 Jan 2012 22:52:24 +0100
Received: by first (Postfix, from userid 1000)
	id 66766154036A; Wed,  4 Jan 2012 22:52:23 +0100 (CET)
Date: Wed, 4 Jan 2012 22:52:23 +0100
From: oliver <oliver@first.in-berlin.de>
To: Damien Doligez <damien.doligez@inria.fr>
Cc: caml users <caml-list@inria.fr>
Message-ID: <20120104215223.GC2740@siouxsie>
References: <1325263446.5036.104.camel@samsung>
 <4EFDEF92.3010204@inria.fr>
 <20120101125212.GB12851@annexia.org>
 <4F0097E6.2090701@inria.fr>
 <1325451843.5036.165.camel@samsung>
 <20120101232429.GA3818@siouxsie>
 <1325462283.5036.189.camel@samsung>
 <20120102014314.GA4960@siouxsie>
 <2015E02F-FBB2-455F-B7C0-A4A478E2F6C3@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <2015E02F-FBB2-455F-B7C0-A4A478E2F6C3@inria.fr>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8
Subject: Re: [Caml-list] Hashtbl and security

On Wed, Jan 04, 2012 at 06:56:11PM +0100, Damien Doligez wrote:
> On 2012-01-02, at 02:43, oliver wrote:
> 
> > If the type is an abstract type, which comes from something like
> > Hashtbl.Randomseed
> > and has type t, not type int, this problem would vanish.
> 
> You have to be careful.  If we make hash table randomization mandatory,
> the Frama-C people will hate us, as will all the people who want
> reproducible results from their programs (for purposes of testing and
> benchmarking, for example).
[...]

I did not meant it must be mandatory.
But provide a way, that makes it easy to use randomization
and not-so-easy to use the always-same values e.g. for testing puroposes.

If it needs extra effort to make simple seed values, people would prefer the randomized ones,
if not they want to write some extra code (maybe applying a functor).


> 
> So, even if randomized is the default, there must be a way to get a
> plain hash table that does the same thing every time.

Yes, of course.

But maybe it should not be encouraged, and the programmer-in-a-hurry would
use ready-to-use random initializations, which are provided by the Hashtbl-module
and the one who needs it non-randomized would need to write his own addition then.

Then the lazy programmer goes safe and the unsafe way needs extra effort.

Nevertheless I think optional int value as a first fix would also be ok.


And maybe some of you remember the Debian random-device bug (some years ago),
where the random-device under certain circumstances ran out of entropy....

So in any case it needs to be possible to change the random generator.

But pseudo-random is always a compromise.
Who really needs true random should of course use special hardware that
creates wide bandwith noise and uses an ADC to sample the signal.

Ciao,
   Oliver