Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Dec 2016 16:51:35 +0100
From: "Jason A. Donenfeld" <>
To: Jean-Philippe Aumasson <>
Cc: George Spelvin <>, Andi Kleen <>, 
	David Miller <>, David Laight <>, 
	Eric Biggers <>, Hannes Frederic Sowa <>,, 
	Linux Crypto Mailing List <>, LKML <>, 
	Andy Lutomirski <>, Netdev <>, 
	Tom Herbert <>, Linus Torvalds <>, 
	"Theodore Ts'o" <>,, 
	"Daniel J . Bernstein" <>
Subject: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi JP & George,

My function names:
- SipHash -> siphash
- HalfSipHash -> hsiphash

It appears that hsiphash can produce either 32-bit output or 64-bit
output, with the output length parameter as part of the hash algorithm
in there. When I code this for my kernel patchset, I very likely will
only implement one output length size. Right now I'm leaning toward
32-bit. Questions:

- Is this a reasonable choice?
- When hsiphash is desired due to its faster speed, are there any
circumstances in which producing a 64-bit output would actually be
useful? Namely, are there any hashtables that could benefit from a
64-bit functions?
- Are there reasons why hsiphash with 64-bit output would be
reasonable? Or will we be fine sticking with 32-bit output only?

With both hsiphash and siphash, the division of usage will probably become:
- Use 64-bit output 128-bit key siphash for keyed RNG-like things,
such as syncookies and sequence numbers
- Use 64-bit output 128-bit key siphash for hashtables that must
absolutely be secure to an extremely high bandwidth attacker, such as
userspace directly DoSing a kernel hashtable
- Use 32-bit output 64-bit key hsiphash for quick hashtable functions
that still must be secure but do not require as large of a security

Sound good?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.