caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Dario Teixeira <darioteixeira@yahoo.com>,
	Gabriel Scherer <gabriel.scherer@gmail.com>,
	David MENTRE <dmentre@linux-france.org>,
	Gerd Stolpmann <info@gerd-stolpmann.de>,
	"Richard W.M. Jones" <rich@annexia.org>,
	caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Hardening [Perl's] hash function further
Date: Wed, 20 Nov 2013 22:47:10 +0100	[thread overview]
Message-ID: <1384984030.11161.19.camel@zotac> (raw)
In-Reply-To: <878uwinbqv.fsf@mid.deneb.enyo.de>

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

Am Mittwoch, den 20.11.2013, 19:56 +0100 schrieb Florian Weimer:
> * Dario Teixeira:
> 
> >  - Any hashtable implementation that uses a non-cryptographic hash function
> >    and relies on an association list of buckets is vulnerable to attacks
> >    that force the worst-case O(n) behaviour.  Though you can buy some time
> >    by tweaking the hash function, you are still stuck in an arms race with
> >    attackers.
> 
> You just need a keyed hash with a secret key, not a general-purpose
> cryptographic hash function.  So far, Jenkins' lookup3 function still
> stands.

The problem is this: You think you add n bits of randomness with the
secret key. But because the hash function isn't cryptographic, there
will be symmetries, and the n bits are actually not worth n bits. And
because there is no cryptanalysis we don't know how safe we are.

You don't need a giant compute centre for finding pairs (secret, keys)
where the keys collide. I'd guess a normal GPU can compute more than
1E11 hashes of that complexity per second. That way you can watch out
for keys that increase the likeliness of a collision. And that's only
the brute force method.

Also, you can test easily 100 or more different series of keys in a
single HTTP request. If you find an attack method where the original n
bits of randomness are, say, only worth 20 bits, you can shoot off the
server process within a couple of minutes. And within an hour the whole
computer. Of course, this is only speculation, but the point is that we
cannot be sure that this isn't possible.

Generally, I think it is better to change the hash table algorithm in
situations where data from untrusted sources is processed. That means
using balanced trees for the buckets. Consumes more RAM, but is provably
safe. (Or, at minimum, limit the length of the buckets.)

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2013-11-20 21:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 20:44 Richard W.M. Jones
2013-11-19  0:08 ` Gerd Stolpmann
2013-11-19  7:53   ` David MENTRE
2013-11-19  8:50     ` Richard W.M. Jones
2013-11-19  9:14     ` Gabriel Scherer
2013-11-19 11:19       ` Dario Teixeira
2013-11-19 12:55         ` rixed
2013-11-19 22:18           ` Nicolas Braud-Santoni
2013-11-19 22:39             ` Eric Cooper
2013-11-19 22:55               ` Nicolas Braud-Santoni
2013-11-25 13:46                 ` Goswin von Brederlow
2013-11-19 22:31         ` Nicolas Braud-Santoni
2013-11-20 18:56         ` Florian Weimer
2013-11-20 21:47           ` Gerd Stolpmann [this message]
2013-11-25 13:51             ` Goswin von Brederlow
2013-11-25 14:43               ` Yaron Minsky
2013-11-19 22:15     ` Nicolas Braud-Santoni
2013-11-25 13:38   ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1384984030.11161.19.camel@zotac \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=darioteixeira@yahoo.com \
    --cc=dmentre@linux-france.org \
    --cc=fw@deneb.enyo.de \
    --cc=gabriel.scherer@gmail.com \
    --cc=rich@annexia.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).