netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "George Spelvin" <linux@horizon.com>
To: herbert@gondor.apana.org.au
Cc: dborkman@redhat.com, hannes@stressinduktion.org,
	linux@horizon.com, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, tgraf@suug.ch
Subject: Re: Where exactly will arch_fast_hash be used
Date: 7 Dec 2014 00:20:41 -0500	[thread overview]
Message-ID: <20141207052041.20498.qmail@ns.horizon.com> (raw)

If you want DoS-resistant hash tables, I'm working on adding SipHash
to the kernel.

This is a keyed pseudo-random function designed specifically for that
application.  I am starting with ext4 directory hashes, and then intended
to expand to secure sequence numbers (since it's far faster than MD5).

(I'm trying to figure out a good interface, since the crypto API
is a bit heavy for something to heavily optimized.)

But one comment caught my eye:
> Even if security wasn't an issue, straight CRC32 has really poor
> lower-order bit distribution, which makes it a terrible choice for
> a hash table that simply uses the lower-order bits.

Er... huh?  That's the first time I've heard that claim, and while I'm not
Philip Koopman or Guy Castagnoli, I thought I understood CRCs pretty well.

CRCs generally mix bits pretty well.  The sparse 16-bit CRCs chosen
for implementation simplicity had some limitations, but the Castagnoli
polynomial is quite dense.

And their mathematical symmetry means that the low bits really shouldn't
be any different from any other bits.  But if it is an issue, it's just
as easy work to shift down the correct number of high bits rather than
using the low.

Can you point me to a source for that statement?

             reply	other threads:[~2014-12-07  5:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-07  5:20 George Spelvin [this message]
2014-12-07  9:28 ` Where exactly will arch_fast_hash be used Herbert Xu
2014-12-07 10:02   ` George Spelvin
2014-12-07 12:51     ` Herbert Xu
2014-12-07 13:23       ` George Spelvin
2014-12-07 14:06         ` Hannes Frederic Sowa
2014-12-07 21:33           ` George Spelvin
2014-12-08 11:25             ` Hannes Frederic Sowa
2014-12-08 16:19               ` George Spelvin
2014-12-08 16:32                 ` Hannes Frederic Sowa
2014-12-09 14:24         ` Herbert Xu
2014-12-07 13:14 ` Hannes Frederic Sowa
2014-12-07 13:30   ` George Spelvin
2014-12-07 13:41     ` Hannes Frederic Sowa
2014-12-07 13:52       ` Hannes Frederic Sowa
  -- strict thread matches above, loose matches on Subject: below --
2014-12-04  8:11 Herbert Xu
2014-12-04 12:34 ` Hannes Frederic Sowa
2014-12-04 13:14   ` Daniel Borkmann
2014-12-04 15:26 ` Thomas Graf
2014-12-04 15:29   ` Herbert Xu
2014-12-04 15:39     ` Thomas Graf
2014-12-04 15:43       ` Daniel Borkmann
2014-12-04 15:47         ` Herbert Xu
2014-12-04 15:51           ` Daniel Borkmann
2014-12-04 15:56           ` David Laight
2014-12-04 16:10             ` Herbert Xu

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=20141207052041.20498.qmail@ns.horizon.com \
    --to=linux@horizon.com \
    --cc=dborkman@redhat.com \
    --cc=hannes@stressinduktion.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@suug.ch \
    /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).