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

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

kernel crash when using sha1 as csums-alg for drbd

Hello, Chandramouli Sorry for last email. These days we experienced 5 times kernel crash issue when using sha1 as csums-alg for drbd on our CentOS7.2 3.10.0-327.el7.x86_64: Kernel log as below: [19839335.792807] BUG: unable to handle kernel paging request at 88007bd4f000 [19839335.793145]

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

On Sun, Dec 11, 2016 at 7:48 PM, Jason A. Donenfeld wrote: > + switch (left) { > + case 7: b |= ((u64)data[6]) << 48; > + case 6: b |= ((u64)data[5]) << 40; > + case 5: b |= ((u64)data[4]) << 32; > + case 4: b |=

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

On Mon, Dec 12, 2016 at 04:48:17AM +0100, Jason A. Donenfeld wrote: > > diff --git a/lib/Makefile b/lib/Makefile > index 50144a3aeebd..71d398b04a74 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -22,7 +22,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ >sha1.o chacha20.o md5.o

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

Hi, Michael & Herbert Because the virtio-crypto device emulation had been in QEMU 2.8, would you please merge the virtio-crypto driver for 4.10 if no other comments? If so, Miachel pls ack and/or review the patch, then Herbert will take it (I asked him last week). Thank you! Ps: Note on 4.10

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: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sun, Dec 11, 2016 at 11:13:55AM -0800, Andy Lutomirski wrote: > On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > > default on x86_64. This has been exposing a number of problems in which

[ANNOUNCE] libkcapi v0.13.0 released

Hi, The Linux kernel exports a network interface of type AF_ALG to allow user space to utilize the kernel crypto API. libkcapi uses this network interface and exports an easy to use API so that a developer does not need to consider the low-level network interface handling. The library does

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote: > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > default on x86_64. This has been exposing a number of problems in which > on-stack buffers are being passed into the crypto API, which to

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

On Sun, Dec 11, 2016 at 04:30:31PM +0100, Jason A. Donenfeld wrote: > 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