[PATCH 2/2] chacha20poly1305: Skip encryption/decryption for 0-len

If the length of the plaintext is zero, there's no need to waste cycles on encryption and decryption. Using the chacha20poly1305 construction for zero-length plaintexts is a common way of using a shared encryption key for AAD authentication. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com&

[PATCH 1/2] blkcipher: Copy iv from desc even for 0-len walks

ing chacha20poly1305 with a zero length input, which then calls chacha20, which calls the key setup routine, which eventually OOPSes due to the uninitialized ->iv member. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: <sta...@vger.kernel.org> --- crypto/ablkcipher.c | 2 +- crypto/blkc

padata - is serial actually serial?

Hi Steffen & Folks, I submit a job to padata_do_parallel(). When the parallel() function triggers, I do some things, and then call padata_do_serial(). Finally the serial() function triggers, where I complete the job (check a nonce, etc). The padata API is very appealing because not only does it

GPF in ChaCha20 SSSE3 Implementation

Hi Martin, I'm trying to use your ChaPoly implementation and I'm running into quite a bit of trouble. Firstly, it appears that the routine intermittently overwrites boundaries that it shouldn't, resulting in panics, which I'm still looking into, and could be caused by error on my part. But, more

Re: GPF in ChaCha20 SSSE3 Implementation

https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg17498.html Eli's patch fixes the issue! I'd recommend you send this off for stable inclusion, as it's potentially remotely exploitable. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message

Non-destructive ChaCha20Poly1305 Decryption

Hi Martin, Your ChaCha20Poly1305 implementation when decrypting calls chacha20 decryption before it verifies the auth tag. Not only does this waste CPU cycles, but it makes it impossible to attempt decryption of cipher texts using different keys (until one is right) without creating a copy, which

Re: [PATCH] crypto: chacha20_4block_xor_ssse3: Align stack pointer to 64 bytes

Can we queue this up for stable too, please? On Mon, Jan 25, 2016 at 2:59 PM, Herbert Xu wrote: > Patch applied. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo

[RFC] WireGuard: next generation secure network tunnel

kernel tree and ditch the backwards-compatibility #ifdefs. Importantly, though, WireGuard doesn't require any modifications in other parts of the kernel, making it nicely standalone. And most of all, the codebase is pretty short; I hope you find it enjoyable to read. I look forward to your feedback

Re: [RFC] WireGuard: next generation secure network tunnel

Hi Richard, On Fri, Jul 1, 2016 at 1:42 PM, Richard Weinberger wrote: > So every logical tunnel will allocate a new net device? > Doesn't this scale badly? I have ipsec alike setups > with many, many road warriors in mind. No, this isn't the case. Each net device

Re: [RFC PATCH] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

Another thing that might be helpful is that you can let gcc decide on the alignment, and then optimize appropriately. Check out what we do with siphash: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/include/linux/siphash.h#n76 static inline u64 siphash(const void *data,

Re: [RFC PATCH] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

Hey, On Thu, Feb 2, 2017 at 7:47 AM, Eric Biggers wrote: > I'm wondering whether it has to be that way, especially since it seems to most > commonly be used on very small input buffers, e.g. 8 or 16-byte blocks. Note that popular stream ciphers like chacha or salsa wind up

Re: [PATCH v3] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

On Sun, Feb 5, 2017 at 11:06 AM, Ard Biesheuvel wrote: > + if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) || > + !((unsigned long)b & (__alignof__(*b) - 1))) Why not simply use the IS_ALIGNED macro? Also, are you might consider checking to see

[PATCH] padata: add helper function for queue length

Since padata has a maximum number of inflight jobs, currently 1000, it's very useful to know how many jobs are currently queued up. This adds a simple helper function to expose this information. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- include/linux/padata.h | 2 ++

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

Hi Eric, On Fri, Nov 4, 2016 at 6:37 PM, Eric Biggers wrote: > I agree, and the current code is wrong; but do note that this proposal is > correct for poly1305_setrkey() but not for poly1305_setskey() and > poly1305_blocks(). In the latter two cases, 4-byte alignment of the

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Mon, Nov 7, 2016 at 7:08 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > Hmm... The general data flow that strikes me as most pertinent is > something like: > > struct sk_buff *skb = get_it_from_somewhere(); > skb = skb_share_check(skb, GFP_ATOMIC); > num_

[PATCH v2] poly1305: generic C can be faster on chips with slow unaligned access

By using the unaligned access helpers, we drastically improve performance on small MIPS routers that have to go through the exception fix-up handler for these unaligned accesses. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/poly1305_generic.c | 12 ++-- 1 file c

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Mon, Nov 7, 2016 at 7:26 PM, Eric Biggers wrote: > > I was not referring to any users in particular, only what users could do. As > an > example, if you did crypto_shash_update() with 32, 15, then 17 bytes, and the > underlying algorithm is poly1305-generic, the last

[PATCH v3] poly1305: generic C can be faster on chips with slow unaligned access

By using the unaligned access helpers, we drastically improve performance on small MIPS routers that have to go through the exception fix-up handler for these unaligned accesses. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/poly1305_generic.

[PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access

By using the unaligned access helpers, we drastically improve performance on small MIPS routers that have to go through the exception fix-up handler for these unaligned accesses. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/poly1305_generic.

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Mon, Nov 7, 2016 at 8:25 PM, Eric Biggers wrote: > No it does *not* buffer all incoming blocks, which is why the source pointer > can > fall out of alignment. Yes, I actually tested this. In fact this situation > is > even hit, in both possible places, in the

Re: [PATCH v3] poly1305: generic C can be faster on chips with slow unaligned access

Hello friendly test robot, On Sun, Nov 13, 2016 at 12:27 AM, kbuild test robot wrote: > Hi Jason, > > [auto build test ERROR on cryptodev/master] That error was fixed by v4 in this series. The version that should be tested and ultimately applied is v4 and can be found here:

[PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On MIPS chips commonly found in inexpensive routers, this makes a big difference in performance. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/poly1305_generic.c | 29 - 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

Hi Herbert, On Thu, Nov 3, 2016 at 1:49 AM, Herbert Xu wrote: > FWIW I'd rather live with a 6% slowdown than having two different > code paths in the generic code. Anyone who cares about 6% would > be much better off writing an assembly version of the code. Please

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

Hi David, On Thu, Nov 3, 2016 at 6:08 PM, David Miller wrote: > In any event no piece of code should be doing 32-bit word reads from > addresses like "x + 3" without, at a very minimum, going through the > kernel unaligned access handlers. Excellent point. In otherwords,

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Wed, Nov 2, 2016 at 9:09 PM, Herbert Xu wrote: > Can you give some numbers please? What about other architectures > that your patch impacts? Per [1], the patch gives a 181% speed up on MIPS32r2. [1]

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

These architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS: s390 arm arm64 powerpc x86 x86_64 So, these will use the original old code. The architectures that will thus use the new code are: alpha arc avr32 blackfin c6x cris frv h7300 hexagon ia64 m32r m68k metag microblaze mips mn10300 nios2

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Wed, Nov 2, 2016 at 10:26 PM, Herbert Xu wrote: > What I'm interested in is whether the new code is sufficiently > close in performance to the old code, particularonly on x86. > > I'd much rather only have a single set of code for all architectures. > After all,

Re: [PATCH] padata: add helper function for queue length

Hi Steffen, On Fri, Oct 7, 2016 at 5:15 AM, Steffen Klassert wrote: > Why you want to have this? I'm working on some bufferbloat/queue code that could benefit from knowing how many items are currently in flight. The goal is to always keep padata busy, but never

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

Hi Herbert, On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu wrote: > As for AEAD we never had a sync interface to begin with and I > don't think I'm going to add one. That's too bad to hear. I hope you'll reconsider. Modern cryptographic design is heading more and more

scatterwalk_map_and_copy incorrect optimization

Hi Herbert, The scatterwalk_map_and_copy function copies ordinary buffers to and from scatterlists. These buffers can, of course, be on the stack, and this remains the most popular use of this function -- getting info between stack buffers and DMA regions. It's mostly used for adding or checking

[PATCH] siphash: add cryptographically secure hashtable function

s a widely known high-speed solution to a widely known problem, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Daniel J. Bernstein <d...@cr.yp.to> --- include/linux/siphash.

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

On Mon, Dec 12, 2016 at 10:44 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > #if defined(CONFIG_DCACHE_WORD_ACCESS) && BITS_PER_LONG == 64 >switch (left) { >case 0: break; >case 1: b |= data[0]; break; >case 2: b |= get_unaligned_le1

[PATCH v3] siphash: add cryptographically secure hashtable function

s a widely known high-speed solution to a widely known problem, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Daniel J. Bernstein <d...@cr.yp.to> --- Changes from v2->v3: - The

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

On Tue, Dec 13, 2016 at 12:01 AM, Andi Kleen wrote: > It would be nice if the network code could be converted to use siphash > for the secure sequence numbers. Right now it pulls in a lot of code > for bigger secure hashes just for that, which is a problem for tiny >

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

Hey Linus, On Mon, Dec 12, 2016 at 5:01 AM, Linus Torvalds wrote: > The above is extremely inefficient. Considering that most kernel data > would be expected to be smallish, that matters (ie the usual benchmark > would not be about hashing megabytes of data, but

[PATCH v2] siphash: add cryptographically secure hashtable function

s a widely known high-speed solution to a widely known problem, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Daniel J. Bernstein <d...@cr.yp.to> --- include/linux/siphash.h |

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

Hi Eric, On Tue, Dec 13, 2016 at 9:39 AM, Eric Biggers wrote: > Hmm, I don't think you can really do load_unaligned_zeropad() without first > checking for 'left != 0'. The fixup section for load_unaligned_zeropad() > assumes that rounding the pointer down to a word boundary

[PATCH v4] siphash: add cryptographically secure hashtable function

s a widely known high-speed solution to a widely known problem, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Daniel J. Bernstein <d...@cr.yp.to> --- Changes from v3->v4: - load_u

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

Hi Linus, On Tue, Dec 13, 2016 at 8:25 PM, Linus Torvalds wrote: > Yeah,. the TCP sequence number md5_transform() cases are likely the > best example of something where siphash might be good. That tends to > be really just a couple words of data (the address and

[PATCH v2 2/4] siphash: add convenience functions for jhash converts

Many jhash users currently rely on the Nwords functions. In order to make transitions to siphash fit something people already know about, we provide analog functions here. This also winds up being nice for the networking stack, where hashing 32-bit fields is common. Signed-off-by: Jason

[PATCH v2 4/4] random: use siphash24 instead of md5 for get_random_int/long

does add a degree of natural entropy. So, in keeping with this design, instead of the massive per-cpu 64-byte md5 state, there is instead a per-cpu previously returned value for chaining. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@

[PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

, 79 insertions(+), 81 deletions(-) diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c index 88a8e429fc3e..abadc79cd5d3 100644 --- a/net/core/secure_seq.c +++ b/net/core/secure_seq.c @@ -1,3 +1,5 @@ +/* Copyright (C) 2016 Jason A. Donenfeld <ja...@zx2c4.com>. All Rights Reserved. */ +

[PATCH v2 1/4] siphash: add cryptographically secure hashtable function

s a widely known high-speed solution to a widely known problem, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Daniel J. Bernstein <d...@cr.yp.to> Cc: Linus Torvalds <torva...@linux-f

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hi David, On Wed, Dec 14, 2016 at 10:56 AM, David Laight wrote: > ... >> +u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN]) > ... >> + u64 k0 = get_unaligned_le64(key); >> + u64 k1 = get_unaligned_le64(key + sizeof(u64)); > ... >> +

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi David, On Wed, Dec 14, 2016 at 10:51 AM, David Laight <david.lai...@aculab.com> wrote: > From: Jason A. Donenfeld >> Sent: 14 December 2016 00:17 >> This gives a clear speed and security improvement. Rather than manually >> filling MD5 buffers, we simply create a l

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hi David & Hannes, This conversation is veering off course. I think this doesn't really matter at all. Gcc converts u64 into essentially a pair of u32 on 32-bit platforms, so the alignment requirements for 32-bit is at a maximum 32 bits. On 64-bit platforms the alignment requirements are related

Re: [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long

Hi David, On Thu, Dec 15, 2016 at 11:14 AM, David Laight <david.lai...@aculab.com> wrote: > From: Behalf Of Jason A. Donenfeld >> Sent: 14 December 2016 18:46 > ... >> + ret = *chaining = siphash24((u8 *), >> offsetof(typeof(combined), end), > > If you

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On Thu, Dec 15, 2016 at 10:45 PM, Hannes Frederic Sowa wrote: > By the way, if you target net-next, it is currently closed. So no need > to hurry. Honestly I have no idea what I'm targeting. The hash function touches lib/. The secure_seq stuff touches net/. The rng

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hi Hannes, Good news. On Thu, Dec 15, 2016 at 10:45 PM, Hannes Frederic Sowa wrote: >> How's that sound? > > I am still very much concerned about the API. Thanks for pushing me and putting up with my daftness... the constant folding works absolutely perfectly. I've

[PATCH v5 1/4] siphash: add cryptographically secure PRF

high-speed solution to a widely known set of problems, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Daniel J. Bernstein <d...@cr.yp.to> Cc: Linus Torvalds <torva...@linux-f

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On Thu, Dec 15, 2016 at 10:17 PM, Hannes Frederic Sowa wrote: > And I was exactly questioning this. > > static unsigned int inet6_hash_frag(__be32 id, const struct in6_addr *saddr, > const struct in6_addr *daddr) > { >

[PATCH v5 3/4] secure_seq: use SipHash in place of MD5

the values directly to the short input convenience functions. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Andi Kleen <a...@linux.intel.com> Cc: David Miller <da...@davemloft.net> Cc: David Laight <david.lai...@aculab.com> Cc: Tom Herbert <t...@herbertland.com>

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa wrote: > ARM64 and x86-64 have memory operations that are not vector operations > that operate on 128 bit memory. Fair enough. imull I guess. > How do you know that the compiler for some architecture will not

[PATCH v5 4/4] random: use SipHash in place of MD5

| -- get_random_long | 137130 | 415983 | 3.03x | get_random_int | 86384 | 343323 | 3.97x | Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Ted Tso <ty...@mit.edu> --- drivers/

Re: [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On Thu, Dec 15, 2016 at 10:09 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Thu, Dec 15, 2016 at 07:50:36PM +0100, Jason A. Donenfeld wrote: >> There's no 32-bit platform >> that will trap on a 64-bit unaligned access because there's no such >> thing as a 64

[PATCH v5 0/4] The SipHash Patchset

your Reviewed-by, so we can begin to get this completed. If there are still lingering issues, let me know and I'll incorporated them into a v6 if necessary. Thanks, Jason Jason A. Donenfeld (4): siphash: add cryptographically secure PRF siphash: add Nu{32,64} helpers secure_seq: use SipHash

[PATCH v5 2/4] siphash: add Nu{32,64} helpers

These restore parity with the jhash interface by providing high performance helpers for common input sizes. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Tom Herbert <t...@herbertland.com> --- include/linux/siphash.h | 33 ++ lib/siphash.c

Re: [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On Thu, Dec 15, 2016 at 10:14 PM, Linus Torvalds wrote: > I think you can/should just use the natural alignment for "u64". > > For architectures that need 8-byte alignment, u64 will already be > properly aligned. For architectures (like x86-32) that only need >

[PATCH v6 4/5] md5: remove from lib and only live in crypto

there are more modern ways of doing what it once achieved. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/md5.c | 95 +++- lib/Makefile | 2 +- lib/md5.c| 95 -

[PATCH v6 2/5] secure_seq: use SipHash in place of MD5

the values directly to the short input convenience functions. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Andi Kleen <a...@linux.intel.com> Cc: David Miller <da...@davemloft.net> Cc: David Laight <david.lai...@aculab.com> Cc: Tom Herbert <t...@herbertland.com>

[PATCH v6 5/5] syncookies: use SipHash in place of SHA1

SHA1 is slower and less secure than SipHash, and so replacing syncookie generation with SipHash makes natural sense. Some BSDs have been doing this for several years in fact. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- net/ipv4/syncookies.c | 20 ne

[PATCH v6 3/5] random: use SipHash in place of MD5

| -- get_random_long | 137130 | 415983 | 3.03x | get_random_int | 86384 | 343323 | 3.97x | Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Ted Tso <ty...@mit.edu> --- drivers/

[PATCH v6 0/5] The SipHash Patchset

useful reviews will still keep the ball moving. Thanks for all the great feedback thus far. Jason Jason A. Donenfeld (5): siphash: add cryptographically secure PRF secure_seq: use SipHash in place of MD5 random: use SipHash in place of MD5 md5: remove from lib and only live in crypto

[PATCH v6 1/5] siphash: add cryptographically secure PRF

s. SipHash is a widely known high-speed solution to a widely known set of problems, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Linus Torvalds <torva...@linux-foundation.org&

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hey JP, On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson wrote: > Here's a tentative HalfSipHash: > https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c > > Haven't computed the cycle count nor measured its speed. This is incredible. Really.

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

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

Hey Eric, Lots of good points; thanks for the review. Responses are inline below. On Mon, Dec 12, 2016 at 6:42 AM, Eric Biggers wrote: > Maybe add to the help text for CONFIG_TEST_HASH that it now tests siphash too? Good call. Will do. > This assumes the key and message

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

Hi Linus, > I guess you could try to just remove the "if (left)" test entirely, if > it is at least partly the mispredict. It should do the right thing > even with a zero count, and it might schedule the code better. Code > size _should_ be better with the byte mask model (which won't matter > in

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

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 <ja...@zx2c4.com> wrote: > I think your suggestion for (2) will contribute to further > optimizations for (1). In v2, I had another patch in there adding >

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On Wed, Dec 14, 2016 at 9:12 PM, Tom Herbert wrote: > If you pad the data structure to 64 bits then we can call the version > of siphash that only deals in 64 bit words. Writing a zero in the > padding will be cheaper than dealing with odd lengths in siphash24. On Wed, Dec

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

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

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

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Daniel J. Bernstein <d...@cr.yp.to> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Eric Biggers <ebigge...@gmail.com> Cc: David Laight <david

[PATCH v3 2/3] secure_seq: use siphash24 instead of md5_transform

e/secure_seq.c @@ -1,3 +1,5 @@ +/* Copyright (C) 2016 Jason A. Donenfeld <ja...@zx2c4.com>. All Rights Reserved. */ + #include #include #include @@ -8,14 +10,14 @@ #include #include #include - +#include #include #if IS_ENABLED(CONFIG_IPV6) || IS_ENABLED(CONFIG_INE

[PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long

does add a degree of natural entropy. So, in keeping with this design, instead of the massive per-cpu 64-byte md5 state, there is instead a per-cpu previously returned value for chaining. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hi Hannes, On Wed, Dec 14, 2016 at 4:09 PM, Hannes Frederic Sowa wrote: > Yes, numbers would be very usable here. I am mostly concerned about > small plastic router cases. E.g. assume you double packet processing > time with a change of the hashing function at what

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi Hannes, On Wed, Dec 14, 2016 at 8:22 PM, Hannes Frederic Sowa wrote: > I don't think this helps. Did you test it? I don't see reason why > padding could be left out between `d' and `end' because of the flexible > array member? Because the type u8 doesn't require

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On Wed, Dec 14, 2016 at 3:47 PM, David Laight wrote: > Just remove the __packed and ensure that the structure is 'nice'. > This includes ensuring there is no 'tail padding'. > In some cases you'll need to put the port number into a 32bit field. I'd rather not. There's no

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi David, On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote: > Just marking the structure __packed, whether necessary or not, makes > the compiler assume that the members are not aligned and causes > byte-by-byte accesses to be performed for words. > Never, _ever_, use

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

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: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hey Ted, On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote: > One somewhat undesirable aspect of the current algorithm is that we > never change random_int_secret. Why exactly would this be a problem? So long as the secret is kept secret, the PRF is secure. If an attacker can

Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hi again, On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote: > [3.606139] random benchmark!! > [3.606276] get_random_int # cycles: 326578 > [3.606317] get_random_int_new # cycles: 95438 > [3.607423] get_random_bytes # cycles: 2653388 Looks to me like my siphash

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

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: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hey Ted, On Wed, Dec 14, 2016 at 8:12 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > I think this opens up a big window for optimizing it even > further. I optimized it a bit further and siphash is now the clear winner over chacha: [1.784801] random benchmark!! [

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

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 v2 1/4] siphash: add cryptographically secure hashtable function

Hi Hannes, On Wed, Dec 14, 2016 at 11:03 PM, Hannes Frederic Sowa wrote: > I fear that the alignment requirement will be a source of bugs on 32 bit > machines, where you cannot even simply take a well aligned struct on a > stack and put it into the normal

[PATCH v4 3/4] secure_seq: use siphash instead of md5_transform

the values directly to the short input convenience functions. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Andi Kleen <a...@linux.intel.com> Cc: David Miller <da...@davemloft.net> Cc: David Laight <david.lai...@aculab.com> Cc: Tom Herbert <t...@herbertland.com>

[PATCH v4 2/4] siphash: add N[qd]word helpers

These restore parity with the jhash interface by providing high performance helpers for common input sizes. Linus doesn't like the use of "qword" and "dword", but I haven't been able to come up with another name for these that fits as well. Signed-off-by: Jason A. Donenfeld

[PATCH v4 1/4] siphash: add cryptographically secure hashtable function

known high-speed solution to a widely known problem, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Daniel J. Bernstein <d...@cr.yp.to> Cc: Linus Torvalds <torva...@linux-foundatio

[PATCH v4 4/4] random: use siphash instead of MD5 for get_random_int/long

| -- get_random_long | 137130 | 415983 | 3.03x | get_random_int | 86384 | 343323 | 3.97x | Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Ted Tso <ty...@mit.edu> --- Changes from v3->v4:

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi George, On Fri, Dec 16, 2016 at 6:36 PM, George Spelvin wrote: > A 128-bit output option was added to SipHash after the initial publication; > this is just the equivalent in 32-bit. > Personally, I'd put in a comment saying that "there's a 64-bit output > variant

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi David, On Fri, Dec 16, 2016 at 6:06 PM, David Laight wrote: > A 32bit hash would also remove all the issues about the alignment > of IP addresses (etc) on 64bit systems. The current replacements of md5_transform with siphash in the v6 patch series will continue to

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi Ted, On Fri, Dec 16, 2016 at 9:43 PM, Theodore Ts'o wrote: > What should we do with get_random_int() and get_random_long()? In > some cases it's being used in performance sensitive areas, and where > anti-DoS protection might be enough. In others, maybe not so much. > > If we

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 9:17 PM, George Spelvin wrote: > My (speaking enerally; I should walk through every hash table you've > converted) opinion is that: > > - Hash tables, even network-facing ones, can all use hsiphash as long > as an attacker can only see

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi Daniel, On Fri, Dec 16, 2016 at 9:44 PM, Daniel Micay wrote: > On Fri, 2016-12-16 at 11:47 -0800, Tom Herbert wrote: >> >> That's about 3x of jhash speed (7 nsecs). So that might closer >> to a more palatable replacement for jhash. Do we lose any security >> advantages

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi George, On Fri, Dec 16, 2016 at 10:25 PM, George Spelvin wrote: > But yes, the sequence number is supposed to be (random base) + (timestamp). > In the old days before Canter & Siegel when the internet was a nice place, > people just used a counter that started at

Re: [PATCH v6 3/5] random: use SipHash in place of MD5

Hi Andy, On Fri, Dec 16, 2016 at 10:31 PM, Andy Lutomirski wrote: > I think it would be nice to try to strenghen the PRNG construction. > FWIW, I'm not an expert in PRNGs, and there's fairly extensive > literature, but I can at least try. In an effort to keep this patchset

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 9:41 PM, George Spelvin wrote: > What are you testing on? And what input size? And does "33% improvement" > mean 4/3 the rate and 3/4 the time? Or 2/3 the time and 3/2 the rate? How that I've published my hsiphash implementation to my tree,

Re: [kernel-hardening] [PATCH] siphash: add cryptographically secure hashtable function

Hi Greg, Thanks for the review. Responses to your suggestions are inline below: On Sat, Dec 10, 2016 at 1:37 PM, Greg KH wrote: > Please use u64 and u8 instead of the userspace uint64_t and uint8_t > types for kernel code. Yes, the ship has probably sailed for

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Sat, Dec 17, 2016 at 3:55 PM, Jeffrey Walton wrote: > It may be prudent to include the endian reversal in the test to ensure > big endian machines produce expected results. Some closely related > testing on an old Apple PowerMac G5 revealed that result needed to be >

Re: HalfSipHash Acceptable Usage

Hi George, On Wed, Dec 21, 2016 at 7:34 AM, George Spelvin wrote: > In fact, I have an idea. Allow me to make the following concrete > suggestion for using HalfSipHash with 128 bits of key material: > > - 64 bits are used as the key. > - The other 64 bits are used as

  1   2   3   >