linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Eric Biggers <ebiggers3@gmail.com>,
	"Daniel J . Bernstein" <djb@cr.yp.to>,
	David Laight <David.Laight@aculab.com>,
	David Miller <davem@davemloft.net>,
	Andi Kleen <ak@linux.intel.com>,
	George Spelvin <linux@sciencehorizons.net>,
	kernel-hardening@lists.openwall.com,
	Andy Lutomirski <luto@amacapital.net>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Tom Herbert <tom@herbertland.com>,
	Vegard Nossum <vegard.nossum@gmail.com>,
	Netdev <netdev@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: HalfSipHash Acceptable Usage
Date: Mon, 19 Dec 2016 18:32:44 +0100	[thread overview]
Message-ID: <CAHmME9rPmH=wP_eHYopt8ZPG9TSN7bos3fGOuqKL2HjQW-2SWA@mail.gmail.com> (raw)

Hi JP,

With the threads getting confusing, I've been urged to try and keep
the topics and threads more closely constrained. Here's where we're
at, and here's the current pressing security concern. It'd be helpful
to have a definitive statement on what you think is best, so we can
just build on top of that, instead of getting lost in the chorus of
opinions.

1) Anything that requires actual long-term security will use
SipHash2-4, with the 64-bit output and the 128-bit key. This includes
things like TCP sequence numbers. This seems pretty uncontroversial to
me. Seem okay to you?

2) People seem to want something competitive, performance-wise, with
jhash if it's going to replace jhash. The kernel community
instinctively pushes back on anything that could harm performance,
especially in networking and in critical data structures, so there
have been some calls for something faster than SipHash. So, questions
regarding this:

2a) George thinks that HalfSipHash on 32-bit systems will have roughly
comparable speed as SipHash on 64-bit systems, so the idea would be to
use HalfSipHash on 32-bit systems' hash tables and SipHash on 64-bit
systems' hash tables. The big obvious question is: does HalfSipHash
have a sufficient security margin for hashtable usage and hashtable
attacks? I'm not wondering about the security margin for other usages,
but just of the hashtable usage. In your opinion, does HalfSipHash cut
it?

2b) While I certainly wouldn't consider making the use case in
question (1) employ a weaker function, for this question (2), there
has been some discussion about using HalfSipHash1-3 (or SipHash1-3 on
64-bit) instead of 2-4. So, the same question is therefore posed:
would using HalfSipHash1-3 give a sufficient security margin for
hashtable usage and hashtable attacks?

My plan is essentially to implement things according to your security
recommendation. The thread started with me pushing a heavy duty
security solution -- SipHash2-4 -- for _everything_. I've received
understandable push back on that notion for certain use cases. So now
I'm trying to discover what the most acceptable compromise is. Your
answers on (2a) and (2b) will direct that compromise.

Thanks again,
Jason

             reply	other threads:[~2016-12-19 17:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-19 17:32 Jason A. Donenfeld [this message]
     [not found] ` <CAGiyFdduUNSGq24zfsk0ZU=hnOCmewAw8vw6XvDoS-3f+3UPKQ@mail.gmail.com>
2016-12-19 21:00   ` Jason A. Donenfeld
2016-12-20 21:36 ` Theodore Ts'o
2016-12-20 23:07   ` George Spelvin
2016-12-20 23:55   ` Eric Dumazet
2016-12-21  3:28     ` George Spelvin
2016-12-21  5:29       ` Eric Dumazet
2016-12-21  6:34         ` George Spelvin
2016-12-21 14:24           ` Jason A. Donenfeld
2016-12-21 15:55             ` George Spelvin
2016-12-21 16:37               ` Jason A. Donenfeld
2016-12-21 16:41               ` [kernel-hardening] " Rik van Riel
2016-12-21 17:25               ` Linus Torvalds
2016-12-21 18:07                 ` George Spelvin
2016-12-22  1:54                 ` Andy Lutomirski
2016-12-21 14:42         ` Jason A. Donenfeld
2016-12-21 15:56           ` Eric Dumazet
2016-12-21 16:33             ` Jason A. Donenfeld
2016-12-21 16:39             ` [kernel-hardening] " Rik van Riel
2016-12-21 17:08               ` Eric Dumazet
2016-12-21 18:37             ` George Spelvin
2016-12-21 18:40               ` Jason A. Donenfeld
2016-12-21 22:27               ` Theodore Ts'o
2016-12-22  0:18                 ` George Spelvin
2016-12-22  1:13                 ` George Spelvin

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='CAHmME9rPmH=wP_eHYopt8ZPG9TSN7bos3fGOuqKL2HjQW-2SWA@mail.gmail.com' \
    --to=jason@zx2c4.com \
    --cc=David.Laight@aculab.com \
    --cc=ak@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=djb@cr.yp.to \
    --cc=ebiggers3@gmail.com \
    --cc=hannes@stressinduktion.org \
    --cc=jeanphilippe.aumasson@gmail.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@sciencehorizons.net \
    --cc=luto@amacapital.net \
    --cc=netdev@vger.kernel.org \
    --cc=tom@herbertland.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=vegard.nossum@gmail.com \
    --subject='Re: HalfSipHash Acceptable Usage' \
    /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

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).