On Sat, Dec 31, 2011 at 01:57:21AM +0100, oliver wrote: > On Fri, Dec 30, 2011 at 06:06:26PM +0100, Xavier Leroy wrote: > > On 12/30/2011 05:44 PM, Gerd Stolpmann wrote: > > > > > 1) Avoid hash tables in contexts where security is relevant. The > > > alternative is Set (actually a balanced binary tree), which does not > > > show this problem. > > > > Highly recommended. Nothing beats guaranteed O(log n) operations. > > > > > 2) Use cryptographically secure hash functions. > > > > Hopeless: with a hash size of 30 bits, as in Caml, or even 64 bits, > > there are no cryptographically secure hash functions. > > > > > 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). > [...] > > > Where is this? > > I found Hashtbl.HashedType.hash with type t -> int.
And there is "val hash_param : int -> int -> 'a -> int" but I'm not sure if this adresses the issue. 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
