Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-17 Thread Christian Kujau
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-17 Thread Christian Kujau
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

RE: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-15 Thread David Laight
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

RE: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-15 Thread David Laight
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. > >

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Linus Torvalds
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.

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Linus Torvalds
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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"

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Linus Torvalds
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.

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Linus Torvalds
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Tom Herbert
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Tom Herbert
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Tom Herbert
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 >>

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Tom Herbert
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread kbuild test robot
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:

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread kbuild test robot
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:

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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,

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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,

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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.

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Tom Herbert
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

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Tom Herbert
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

[PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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

[PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-14 Thread Jason A. Donenfeld
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