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 pBULGOju030969 for ; Fri, 30 Dec 2011 22:16:26 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkBANUo/k7U436rkWdsb2JhbABDhQ+nRCIBAQEBCQsLBxQDIoFyAQEEASMEUhALGgImAgJXBhMJh3ECBqQVkTeBL4JOhnyBFgSNGo03jGY X-IronPort-AV: E=Sophos;i="4.71,434,1320620400"; d="scan'208";a="125102860" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Dec 2011 22:16:26 +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=mrbap0) with ESMTP (Nemesis) id 0MaDyS-1RN02D3CkC-00KINX; Fri, 30 Dec 2011 22:16:25 +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 5766CC00C7; Fri, 30 Dec 2011 22:16:25 +0100 (CET) From: Gerd Stolpmann To: Xavier Leroy Cc: caml-list@inria.fr In-Reply-To: <4EFDEF92.3010204@inria.fr> References: <1325263446.5036.104.camel@samsung> <4EFDEF92.3010204@inria.fr> Content-Type: text/plain; charset="UTF-8" Date: Fri, 30 Dec 2011 22:16:24 +0100 Message-ID: <1325279784.5036.113.camel@samsung> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:yio5i2XuylLx4QslMSeR8OONMFw+ZPx72Koxrc4gUcr H0rgJf0s4EEnNEUa7Xx/aLIRHCi49yIhFC4I1WATo7OekEylu5 iNf9qxP8pgEU8hb2kxwTuwygxZ1OetN8P4OibUjN+NH2gcKuo5 tZ9j6dLVooraZI5IBDtyR/mxkySBbJZ3I/HW45o8H2SnR091N1 0m3xinAd+iZ3iWy6fbjg7Q4rY11ms26e/SRSMBhaPS29pXkct5 EKseTLoYeN6O7A2jvI1Z4SyusFYlo+orGJxtM9mAUzqik7I+Aq IZEd+qDZqyx36AvEtf3cvqOnkPAZAt8wzHO81jLAHksznr7Uo+ a/1Y+NW4s6jV+mYL6RNu91Photz5rlZKKHo6C6VYG Subject: Re: [Caml-list] Hashtbl and security Am Freitag, den 30.12.2011, 18:06 +0100 schrieb Xavier Leroy: > > 3) Use "randomized" hash tables. The trick here is that there is not a > > single hash function h anymore, but a family h(1)...h(n). When the hash > > table is created, one of the functions is picked randomly. This makes it > > impossible to craft an attack request, because you cannot predict the > > function. > > Indeed. The optional "seed" parameter to Hashtbl.create does exactly > this in the new implementation of Hashtbl (the one based on Murmur3). I see. It will be available in 3.13: val create : ?seed:int -> int -> ('a, 'b) t There is also an additional functorized interface where this seed argument exists (Hashtbl.MakeSeeded), and the hash functions seeded_hash and seeded_hash_param. Well done! Nevertheless, as we all don't know when 3.13 is ready, I'll have to find a temporary fix for Ocamlnet. Maybe just a limit for the number of POST parameters. > > So, the question is how to do 3). I see two problems here: > > > > a) how to define the family of hash functions. Is it e.g. sufficient to > > introduce an initialization vector for the Murmurhash algorithm, and > > fill it randomly? > > IIRC, the Web pages for the Murmur family of hashes gives some > statistical evidence that this approach works. > > > How to get a random number that is good enough? > > Hmm. /dev/random is your friend on the platforms that support it. > Otherwise, there's always the Random module, but Random.self_init > isn't very strong. Well, /dev/(u)random covers most Unix platforms nowadays. If you are interested, I have a wrapper for Win32: https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netsys/netsys_c_win32.c Scroll down until netsys_fill_random. 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 ------------------------------------------------------------