SipHash is a 64-bit keyed hash function that is actually a
cryptographically secure PRF, like HMAC. Except SipHash is super fast,
and is meant to be used as a hashtable keyed lookup function.
SipHash isn't just some new trendy hash function. It's been around for a
while, and there really isn't any
On Wed, Dec 14, 2016 at 10:46 AM, Jason A. Donenfeld wrote:
> SipHash is a 64-bit keyed hash function that is actually a
> cryptographically secure PRF, like HMAC. Except SipHash is super fast,
> and is meant to be used as a hashtable keyed lookup function.
>
"super fast" is relative. My quick tes
Hi Tom,
On Wed, Dec 14, 2016 at 8:18 PM, Tom Herbert wrote:
> "super fast" is relative. My quick test shows that this faster than
> Toeplitz (good, but not exactly hard to achieve), but is about 4x
> slower than jhash.
Fast relative to other cryptographically secure PRFs.
>> SipHash isn't just
Hey Tom,
Just following up on what I mentioned in my last email...
On Wed, Dec 14, 2016 at 8:35 PM, Jason A. Donenfeld wrote:
> I think your suggestion for (2) will contribute to further
> optimizations for (1). In v2, I had another patch in there adding
> siphash_1word, siphash_2words, etc, lik
Hi Jason,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9 next-20161214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/siphash-add-cryptographically-sec
Interesting. Evidently gcc 4.8 doesn't like my use of:
enum siphash_lengths {
SIPHASH24_KEY_LEN = 16,
SIPHASH24_ALIGNMENT = 8
};
I'll convert this to the more boring:
#define SIPHASH24_KEY_LEN 16
#define SIPHASH24_ALIGNMENT 8
--
To unsubscribe from this list: send the line "unsubsc
On Wed, Dec 14, 2016 at 12:55 PM, Jason A. Donenfeld wrote:
> Hey Tom,
>
> Just following up on what I mentioned in my last email...
>
> On Wed, Dec 14, 2016 at 8:35 PM, Jason A. Donenfeld wrote:
>> I think your suggestion for (2) will contribute to further
>> optimizations for (1). In v2, I had
Hey Tom,
On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert wrote:
> Those look good, although I would probably just do 1,2,3 words and
> then have a function that takes n words like jhash. Might want to call
> these dword to distinguish from 32 bit words in jhash.
So actually jhash_Nwords makes no s
On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld wrote:
> Hey Tom,
>
> On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert wrote:
>> Those look good, although I would probably just do 1,2,3 words and
>> then have a function that takes n words like jhash. Might want to call
>> these dword to distingu
Hey Tom,
On Thu, Dec 15, 2016 at 12:14 AM, Tom Herbert wrote:
> I'm confused, doesn't 2dword == 1qword? Anyway, I think the qword
> functions are good enough. If someone needs to hash over some odd
> length they can either put them in a structure padded to 64 bits or
> call the hash function that
On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld wrote:
>
> So actually jhash_Nwords makes no sense, since it takes dwords
> (32-bits) not words (16-bits). The siphash analog should be called
> siphash24_Nqwords.
No. The bug is talking about "words" in the first place.
Depending on your backg
Hey Linus,
On Thu, Dec 15, 2016 at 12:30 AM, Linus Torvalds
wrote:
> No. The bug is talking about "words" in the first place.
>
> Depending on your background, a "word" can be generally be either 16
> bits or 32 bits (or, in some cases, 18 bits).
>
> In theory, a 64-bit entity can be a "word" too
On Wed, Dec 14, 2016 at 3:34 PM, Jason A. Donenfeld wrote:
>
> Or does your reasonable dislike of "word" still allow for the use of
> dword and qword, so that the current function names of:
dword really is confusing to people.
If you have a MIPS background, it means 64 bits. While to people with
From: Linus Torvalds
> Sent: 15 December 2016 00:11
> On Wed, Dec 14, 2016 at 3:34 PM, Jason A. Donenfeld wrote:
> >
> > Or does your reasonable dislike of "word" still allow for the use of
> > dword and qword, so that the current function names of:
>
> dword really is confusing to people.
>
> If
On Thu, 15 Dec 2016, Jason A. Donenfeld wrote:
> > I'd still drop the "24" unless you really think we're going to have
> > multiple variants coming into the kernel.
>
> Okay. I don't have a problem with this, unless anybody has some reason
> to the contrary.
What if the 2/4-round version falls an
15 matches
Mail list logo