linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: George Spelvin <linux@sciencehorizons.net>,
	"Ted Ts'o" <tytso@mit.edu>, Andi Kleen <ak@linux.intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	David Laight <David.Laight@aculab.com>,
	"D. J. Bernstein" <djb@cr.yp.to>,
	Eric Biggers <ebiggers3@gmail.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	Tom Herbert <tom@herbertland.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Vegard Nossum <vegard.nossum@gmail.com>
Subject: Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)
Date: Thu, 22 Dec 2016 03:40:00 +0100	[thread overview]
Message-ID: <CAHmME9qWXQ_SA6f5m9Aa0J5otNqesoCF=p+RAW53fv0K+bMH7A@mail.gmail.com> (raw)

> On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin
>> After some thinking, I still like the "state-preserving" construct
>> that's equivalent to the current MD5 code.  Yes, we could just do
>> siphash(current_cpu || per_cpu_counter, global_key), but it's nice to
>> preserve a bit more.
>>
>> It requires library support from the SipHash code to return the full
>> SipHash state, but I hope that's a fair thing to ask for.

This is not a good idea. If I understand correctly, the idea here is
to just keep around SipHash's internal state variables, and chain them
over to the next call, sort of like how md5_transform with the current
code works on the same scratch space. There has been no security
analysis in the literature on this use of the primitive, and I have no
confidence that this is a secure use of the function. Unless somebody
can point me toward a paper I missed or a comment from a real
cryptographer about the specifics of SipHash, I think I'm right to
admonish against this dangerous road.

Let's talk about constructions. And let's only decide on a
construction that we're actually equipped to analyze. Let's definitely
not talk about making our own primitives, or retrofitting nice
primitive's internals into our own Frankenstein.

Alternatively, if I'm wrong, please send me an eprint/arXiv link to a
paper that discusses this use of SipHash.

             reply	other threads:[~2016-12-22  2:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-22  2:40 Jason A. Donenfeld [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-12-22  2:07 George's crazy full state idea (Re: HalfSipHash Acceptable Usage) Andy Lutomirski
2016-12-22  5:01 ` George Spelvin
2016-12-22  5:42   ` Andy Lutomirski
2016-12-22  8:02     ` George Spelvin
2016-12-22 16:09 ` Andy Lutomirski
2016-12-22 19:24   ` George Spelvin
2016-12-22 19:32     ` Andy Lutomirski
2016-12-22 21:11       ` George Spelvin
2016-12-22 21:38         ` Hannes Frederic Sowa
2016-12-23  0:07           ` George Spelvin
2016-12-23 12:05             ` Hannes Frederic Sowa
2016-12-23 18:26               ` George Spelvin
2016-12-23 20:48                 ` Hannes Frederic Sowa
2016-12-23 23:39                   ` George Spelvin
2016-12-24  0:12                     ` Hannes Frederic Sowa
2016-12-24  1:17                       ` George Spelvin
2016-12-28  5:23                         ` Hannes Frederic Sowa
2016-12-28 10:04                           ` 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='CAHmME9qWXQ_SA6f5m9Aa0J5otNqesoCF=p+RAW53fv0K+bMH7A@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=eric.dumazet@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@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tom@herbertland.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=vegard.nossum@gmail.com \
    /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).