Re: [RFC PATCH v2] crypto: Add IV generation algorithms

Hi Milan, On 13 December 2016 at 15:31, Milan Broz wrote: > I think that IV generators should not modify or read encrypted data directly, > it should only generate IV. I was trying to find more information about what you said and how a iv generator should be written. I saw

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

Jean-Philippe Aumasson wrote: > If a halved version of SipHash can bring significant performance boost > (with 32b words instead of 64b words) with an acceptable security level > (64-bit enough?) then we may design such a version. It would be fairly significant, a 2x speed benefit on a lot of

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

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, or as a general PRF for short input use cases, such as sequence numbers or RNG chaining. For the first

[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 --- net/ipv4/syncookies.c | 20

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

This duplicates the current algorithm for get_random_int/long, but uses siphash instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also separates hashed fields into three values instead of one, in order to increase diffusion.

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

The md5_transform function is no longer used any where in the tree, except for the crypto api's actual implementation of md5, so we can drop the function from lib and put it as a static function of the crypto file, where it belongs. There should be no new users of md5_transform, anyway, since

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

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, for IPv6, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. For IPv4, we pass the

[PATCH v6 0/5] The SipHash Patchset

Hey again, This keeps getting more ambitious, which is good I suppose. If the frequency of new versioned patchsets is too high for LKML and not customary, please let me know. Otherwise, read on to see what's new this time... With Hannes' suggestion, there is now only one siphash() function,

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

Hi Jason, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161215] [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

RE: [virtio-dev] Re: [Qemu-devel] [PATCH v7 1/1] crypto: add virtio-crypto driver

Hi Michael, > > > > > > > > Subject: RE: [Qemu-devel] [PATCH v7 1/1] crypto: add virtio-crypto driver > > > > > > On Thursday, December 15, 2016 8:45 AM, Gonglei (Arei) Wrote: > > > < > > diff --git a/drivers/crypto/virtio/virtio_crypto_core.c > > > < >

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

On 16.12.2016 00:43, Jason A. Donenfeld wrote: > 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

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

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

> If a halved version of SipHash can bring significant performance boost > (with 32b words instead of 64b words) with an acceptable security level > (64-bit enough?) then we may design such a version. I was thinking if the key could be pushed to 80 bits, that would be nice, but honestly 64 bits

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

> While SipHash is extremely fast for a cryptographically secure function, > it is likely a tiny bit slower than the insecure jhash, and so replacements > will be evaluated on a case-by-case basis based on whether or not the > difference in speed is negligible and whether or not the current jhash

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

On Thu, Dec 15, 2016 at 09:43:04PM +0100, Jason A. Donenfeld wrote: > 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

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

On 15.12.2016 22:25, Jason A. Donenfeld wrote: > 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, >>

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) > { >

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

On 15.12.2016 21:43, Jason A. Donenfeld wrote: > 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

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 >

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

On Thu, Dec 15, 2016 at 1:11 PM, Jason A. Donenfeld wrote: > > Indeed, I stand corrected. But in any case, the use of __aligned(8) in > the patchset ensures that things are fixed and that we don't have this > issue. I think you can/should just use the natural alignment for

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 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-bit access there. In short,

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

On 15.12.2016 22:04, Peter Zijlstra wrote: > On Thu, Dec 15, 2016 at 09:43:04PM +0100, Jason A. Donenfeld wrote: >> 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

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

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-bit access there. In short, we're fine. ARMv7 LPAE is a 32bit architecture that has 64bit load/stores IIRC. x86

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 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 Cc: Tom Herbert --- include/linux/siphash.h | 33 ++ lib/siphash.c | 157

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

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, or as a general PRF for short input use cases, such as sequence numbers or RNG chaining. For the first

[PATCH v5 0/4] The SipHash Patchset

Hey folks, I think we're approaching the end of the review for this patchset and we're getting somewhat close to being ready for it being queued up. At this point, I've incorporated all of the extremely helpful and instructive suggestions from the list. For this v5, we now accept u64[2] as the

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

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, for IPv6, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. For IPv4, we pass the

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

Hello, On 15.12.2016 19:50, Jason A. Donenfeld wrote: > Hi David & Hannes, > > This conversation is veering off course. Why? > 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 >

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

This duplicates the current algorithm for get_random_int/long, but uses siphash instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also separates hashed fields into three values instead of one, in order to increase diffusion.

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 wrote: > From: Behalf Of Jason A. Donenfeld >> Sent: 14 December 2016 18:46 > ... >> + ret = *chaining = siphash24((u8 *), >> offsetof(typeof(combined), end), > > If you make the first argument 'const void *'

Re: [Qemu-devel] [PATCH v7 1/1] crypto: add virtio-crypto driver

On Thu, Dec 15, 2016 at 01:08:51AM +, Gonglei (Arei) wrote: > > > > > Regards, > -Gonglei > > > > -Original Message- > > From: Zeng, Xin [mailto:xin.z...@intel.com] > > Sent: Thursday, December 15, 2016 8:59 AM > > To: Gonglei (Arei); Halil Pasic; linux-ker...@vger.kernel.org; >

Crypto Fixes for 4.10

Hi Linus: This push fixes the following issues: - A crash regression in the new skcipher walker. - Incorrect return value in public_key_verify_signature. - Fix for in-place signing in the sign-file utility. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git

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

On 15.12.2016 16:41, David Laight wrote: > Try (retyped): > > echo 'struct { long a; long long b; } s; int bar { return sizeof s; }' >foo.c > gcc [-m32] -O2 -S foo.c; cat foo.s > > And look at what is generated. I used __alignof__(unsigned long long) with -m32. >> Right now ipv6 addresses have

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

From: Hannes Frederic Sowa > Sent: 15 December 2016 14:57 > On 15.12.2016 14:56, David Laight wrote: > > From: Hannes Frederic Sowa > >> Sent: 15 December 2016 12:50 > >> On 15.12.2016 13:28, David Laight wrote: > >>> From: Hannes Frederic Sowa > Sent: 15 December 2016 12:23 > >>> ... >

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

On 15.12.2016 14:56, David Laight wrote: > From: Hannes Frederic Sowa >> Sent: 15 December 2016 12:50 >> On 15.12.2016 13:28, David Laight wrote: >>> From: Hannes Frederic Sowa Sent: 15 December 2016 12:23 >>> ... Hmm? Even the Intel ABI expects alignment of unsigned long long to be 8

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

From: Hannes Frederic Sowa > Sent: 15 December 2016 12:50 > On 15.12.2016 13:28, David Laight wrote: > > From: Hannes Frederic Sowa > >> Sent: 15 December 2016 12:23 > > ... > >> Hmm? Even the Intel ABI expects alignment of unsigned long long to be 8 > >> bytes on 32 bit. Do you question that? > >

[PATCH -resend with CC] crypto: algif_hash, avoid zero-sized array

With this reproducer: struct sockaddr_alg alg = { .salg_family = 0x26, .salg_type = "hash", .salg_feat = 0xf, .salg_mask = 0x5, .salg_name = "digest_null", }; int sock, sock2; sock = socket(AF_ALG, SOCK_SEQPACKET, 0); bind(sock, (struct

Re: [PATCH] crypto: skcipher - fix crash in virtual walk

On 12/14/2016 11:39 AM, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 01:34:02PM +, Ard Biesheuvel wrote: >> The new skcipher walk API may crash in the following way. (Interestingly, >> the tcrypt boot time tests seem unaffected, while an explicit test using >> the module triggers it) >> >>

Re: [PATCH v2 0/3] Add Support for Cavium Cryptographic Accelerarion Unit

Hi, I got few review comments for this series from David Daney. I am reworking on this series and will sent v3 once it is done. So,kindly ignore this series Regards, -George On 12/13/2016 07:33 PM, George Cherian wrote: This series adds the support for Cavium Cryptographic Accelerarion Unit

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

On 15.12.2016 13:28, David Laight wrote: > From: Hannes Frederic Sowa >> Sent: 15 December 2016 12:23 > ... >> Hmm? Even the Intel ABI expects alignment of unsigned long long to be 8 >> bytes on 32 bit. Do you question that? > > Yes. > > The linux ABI for x86 (32 bit) only requires 32bit

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

From: Hannes Frederic Sowa > Sent: 15 December 2016 12:23 ... > Hmm? Even the Intel ABI expects alignment of unsigned long long to be 8 > bytes on 32 bit. Do you question that? Yes. The linux ABI for x86 (32 bit) only requires 32bit alignment for u64 (etc). David

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

On 15.12.2016 12:04, David Laight wrote: > From: Hannes Frederic Sowa >> Sent: 14 December 2016 22:03 >> On 14.12.2016 13:46, Jason A. Donenfeld wrote: >>> Hi David, >>> >>> On Wed, Dec 14, 2016 at 10:56 AM, David Laight >>> wrote: ... > +u64 siphash24(const u8

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

From: Hannes Frederic Sowa > Sent: 14 December 2016 22:03 > On 14.12.2016 13:46, Jason A. Donenfeld wrote: > > Hi David, > > > > On Wed, Dec 14, 2016 at 10:56 AM, David Laight > > wrote: > >> ... > >>> +u64 siphash24(const u8 *data, size_t len, const u8 > >>>

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

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 3/3] random: use siphash24 instead of md5 for get_random_int/long

From: Behalf Of Jason A. Donenfeld > Sent: 14 December 2016 18:46 ... > + ret = *chaining = siphash24((u8 *), offsetof(typeof(combined), > end), If you make the first argument 'const void *' you won't need the cast on every call. I'd also suggest making the key u64[2]. David -- To

[PATCH 2/2] crypto: bfin_crc: Remove unneeded linux/miscdevice.h include

bfin_crc.h driver does not use any miscdevice, so this patch remove this unnecessary inclusion. Signed-off-by: Corentin Labbe --- drivers/crypto/bfin_crc.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/crypto/bfin_crc.h b/drivers/crypto/bfin_crc.h index

[PATCH 1/2] crypto: bfin_crc: Fix format printing warning

bfin_crc.c print some u32 as unsigned long ans so gcc complains about it. This patch remove the long print qualifier. Signed-off-by: Corentin Labbe --- drivers/crypto/bfin_crc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

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

On 15.12.2016 00:29, Jason A. Donenfeld wrote: > 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

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

On Thu, 2016-12-15 at 15:57 +0800, Herbert Xu wrote: > Jason A. Donenfeld wrote: > > > > Siphash needs a random secret key, yes. The point is that the hash > > function remains secure so long as the secret key is kept secret. > > Other functions can't make the same guarantee,

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

Jason A. Donenfeld wrote: > > Siphash needs a random secret key, yes. The point is that the hash > function remains secure so long as the secret key is kept secret. > Other functions can't make the same guarantee, and so nervous periodic > key rotation is necessary, but in most