Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

On Thu, Dec 15, 2016 at 12:47:16AM +0530, PrasannaKumar Muralidharan wrote: > Should there be a mandate that driver will be accepted only when it > passes 'rngtest'. This will make sure that prng drivers won't get > added in future. You cannot use software to distinguish between a PRNG and an

[PATCH 0/8] enable endian checks for all sparse builds

This is just a reposting of the patch that enables endian checks, with addition of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere. I plan to include this in my pull request unless I hear otherwise. Michael S. Tsirkin (8): linux/types.h: enable endian checks for all

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

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:

[PATCH v8 1/1] crypto: add virtio-crypto driver

This patch introduces virtio-crypto driver for Linux Kernel. The virtio crypto device is a virtual cryptography device as well as a kind of virtual hardware accelerator for virtual machines. The encryption anddecryption requests are placed in the data queue and are ultimately handled by

[PATCH v8 0/1] virtio-crypto: add Linux driver

v8: - use per virtqueue lock instead of a whole device lock for data virtuqueue. [Halil & Xin] v7: - fix "BUG: smp_processor_id() in preemptible [] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion

[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 Cc:

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

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

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. There are a variety of attacks known as "hashtable poisoning" in which an attacker forms some data such

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

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: [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 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!! [1.785161]

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

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; > qemu-de...@nongnu.org; virtio-...@lists.oasis-open.org; >

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 < > b/drivers/crypto/virtio/virtio_crypto_core.c < > > new file mode 100644 < > > index 000..c0854a1 < > > --- /dev/null < > > +++

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

> > > On 12/14/2016 12:50 PM, Gonglei wrote: > > diff --git a/drivers/crypto/virtio/virtio_crypto_core.c > b/drivers/crypto/virtio/virtio_crypto_core.c > > new file mode 100644 > > index 000..c0854a1 > > --- /dev/null > > +++ b/drivers/crypto/virtio/virtio_crypto_core.c > > @@ -0,0 +1,474

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

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

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

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: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

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

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

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 key[SIPHASH24_KEY_LEN]) >> ... >>> + u64 k0 = get_unaligned_le64(key); >>> + u64

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

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

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

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

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

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

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

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

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

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

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 v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hey Jason, On 14.12.2016 20:38, Jason A. Donenfeld wrote: > 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

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

On Wed, Dec 14, 2016 at 4:53 AM, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 10:51 AM, David Laight > wrote: >> From: Jason A. Donenfeld >>> Sent: 14 December 2016 00:17 >>> This gives a clear speed and security improvement. Rather

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 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: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On 14.12.2016 19:06, Jason A. Donenfeld wrote: > 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

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

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 v2] crypto: sun4i-ss: support the Security System PRNG

>> I have found two solutions: > > No we already have algif_rng so let's not confuse things even > further by making hwrng take PRNGs. Even if both the solutions could not be adopted I think there must be a way for applications to use similar API to get true rng or prng. Given the case that no

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

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

This duplicates the current algorithm for get_random_int/long, but uses siphash24 instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also hashes the pid, entropy, and timestamp as fixed width fields, in order to increase

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

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 2/3] secure_seq: use siphash24 instead of md5_transform

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, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. Signed-off-by: Jason A.

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: [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: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

From: "Jason A. Donenfeld" Date: Wed, 14 Dec 2016 13:53:10 +0100 > In all current uses of __packed in the code, I think the impact is > precisely zero, because all structures have members in descending > order of size, with each member being a perfect multiple of the one > below

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] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > David, are these encrypted keys ever exported anywhere? If not, could > the code use a mode that doesn't need padding? ecryptfs uses them, I think. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

On Tue, Dec 13, 2016 at 08:40:00AM -0800, Andy Lutomirski wrote: > But I think this is rather silly. Joerg, Linus, etc: would it be okay > to change lib/dma-debug.c to allow DMA *from* rodata? Yeah, this would be fine for DMA_TO_DEVICE mappings. At least I can't think of a reason right now to

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

On Wed, Dec 14, 2016 at 04:10:37AM +0100, Jason A. Donenfeld wrote: > This duplicates the current algorithm for get_random_int/long, but uses > siphash24 instead. This comes with several benefits. It's certainly > faster and more cryptographically secure than MD5. This patch also > hashes the pid,

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

On 12/14/2016 12:50 PM, Gonglei wrote: > diff --git a/drivers/crypto/virtio/virtio_crypto_core.c > b/drivers/crypto/virtio/virtio_crypto_core.c > new file mode 100644 > index 000..c0854a1 > --- /dev/null > +++ b/drivers/crypto/virtio/virtio_crypto_core.c > @@ -0,0 +1,474 @@ [..] > + >

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

Hello, On 14.12.2016 14:10, Jason A. Donenfeld wrote: > On Wed, Dec 14, 2016 at 12:21 PM, Hannes Frederic Sowa > wrote: >> Can you show or cite benchmarks in comparison with jhash? Last time I >> looked, especially for short inputs, siphash didn't beat jhash (also on

Re: [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.

I will rebase to Herbert's latest when I submit v3 to address Mark Rutland's DT comments (and any others that come in). Rob On 12/10/2016 7:14 PM, kbuild test robot wrote: Hi Rob, [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.9-rc8] [cannot apply to next-20161209]

[PATCH v2] crypto: marvell - Copy IVDIG before launching partial DMA ahash requests

Currently, inner IV/DIGEST data are only copied once into the hash engines and not set explicitly before launching a request that is not a first frag. This is an issue especially when multiple ahash reqs are computed in parallel or chained with cipher request, as the state of the request being

[PATCH] crypto: marvell - Copy IVDIG before launching partial DMA ahash requests

Currently, inner IV/DIGEST data are only copied once into the hash engines and not set explicitly before launching a request that is not a first frag. This is an issue especially when multiple ahash reqs are computed in parallel or chained with cipher request, as the state of the request being

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

On 14.12.2016 13:53, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 10:51 AM, David Laight > wrote: >> From: Jason A. Donenfeld >>> Sent: 14 December 2016 00:17 >>> This gives a clear speed and security improvement. Rather than manually >>> filling

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 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 layout by a simple anonymous

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)); > ... >> +

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

This patch introduces virtio-crypto driver for Linux Kernel. The virtio crypto device is a virtual cryptography device as well as a kind of virtual hardware accelerator for virtual machines. The encryption anddecryption requests are placed in the data queue and are ultimately handled by

[PATCH v7 0/1] virtio-crypto: add Linux driver

v7: - fix "BUG: smp_processor_id() in preemptible [] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion in virtcrypto_dataq_callback(), we should release the spinlock before invoking the callback. -

RE: [PATCH v6 2/2] crypto: add virtio-crypto driver

Hi, > > Subject: Re: [PATCH v6 2/2] crypto: add virtio-crypto driver > > > > On 12/12/2016 11:05 PM, Michael S. Tsirkin wrote: > > On Mon, Dec 12, 2016 at 06:54:07PM +0800, Herbert Xu wrote: > >> On Mon, Dec 12, 2016 at 06:25:12AM +, Gonglei (Arei) wrote: > >>> Hi, Michael & Herbert > >>>

Re: [PATCH 1/2] crypto: asymmetric_keys: set error code on failure

On Tue, Dec 13, 2016 at 09:26:18AM +, David Howells wrote: > From: Pan Bian > > In function public_key_verify_signature(), returns variable ret on > error paths. When the call to kmalloc() fails, the value of ret is 0, > and it is not set to an errno before returning.

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

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) > > Unable to handle kernel NULL pointer dereference

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > > - sg_set_buf(_out[1], pad, sizeof pad); > > + sg_set_buf(_out[1], empty_zero_page, 16); > > My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what > exactly is the code trying to do? The old code makes no sense. It's

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

On Wed, Dec 14, 2016 at 01:04:04PM +0800, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 06:53:03PM -0800, Andy Lutomirski wrote: > > On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote: > > > The driver put a constant buffer of all zeros on the stack and > > > pointed a