Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On Tue, Jul 18, 2017 at 08:57:28AM +0100, Ard Biesheuvel wrote: > > So if you care about security and/or the cache/memory footprint more > than about speed, you can disable the table based implementations that > exist for i586, x86, ARM and arm64 (all of which have faster and time > invariant

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

On Tue, Jul 18, 2017 at 09:57:55AM +0200, Stephan Müller wrote: > --- /dev/null > +++ b/include/crypto/jitterentropy.h > @@ -0,0 +1,80 @@ > +/* > + * Copyright (C) 2017, Stephan Mueller > + * > + * Redistribution and use in source and binary forms, with or without > + *

Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

On Tue, Jul 18, 2017 at 9:58 AM, Stephan Müller wrote: > When selecting the LRNG for compilation, disable add_disk_randomness and > its supporting function. > > CC: Greg Kroah-Hartman > CC: Arnd Bergmann > CC: Jason A. Donenfeld

[RFC PATCH v12 4/4] LRNG - enable compile

Add LRNG compilation support. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld Signed-off-by: Stephan Mueller --- drivers/char/Kconfig | 10 ++ drivers/char/Makefile | 10 +- 2

[RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

When selecting the LRNG for compilation, disable add_disk_randomness and its supporting function. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld Signed-off-by: Stephan Mueller ---

[RFC PATCH v12 0/4] /dev/random - a new approach

Hi, after distributing patches for the Linux-RNG - a new approach for the last half year, I would like to submit this RFC for inclusion into the kernel. The following patch set provides a different approach to /dev/random which I call Linux Random Number Generator (LRNG) to collect entropy

[RFC PATCH v12 3/4] Linux Random Number Generator

The LRNG with the following properties: * noise source: interrupts timing with fast boot time seeding * lockless LFSR to collect raw entropy * use of standalone ChaCha20 based RNG with the option to use a different DRNG selectable at compile time * "atomic" seeding of secondary DRBG to

[RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

To support the LRNG operation which allocates the Jitter RNG separately from the kernel crypto API, extract the relevant information into a separate header file. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld

Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On 18 July 2017 at 08:18, Herbert Xu wrote: > On Tue, Jul 18, 2017 at 07:32:41AM +0100, Ard Biesheuvel wrote: >> >> Because it is slower, and how much slower is architecture dependent >> (if your arch has slow multiplication, aes-ti decryption will be dog >> slow

Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On Tue, Jul 18, 2017 at 07:32:41AM +0100, Ard Biesheuvel wrote: > > Because it is slower, and how much slower is architecture dependent > (if your arch has slow multiplication, aes-ti decryption will be dog > slow compared to aes-generic) Right, but does anybody actually care? My guess is that on

Re: [PATCH V2 6/6] crypto/nx: Add P9 NX support for 842 compression engine

On Mon, Jul 17, 2017 at 04:50:38PM -0700, Haren Myneni wrote: > > This patch adds P9 NX support for 842 compression engine. Virtual > Accelerator Switchboard (VAS) is used to access 842 engine on P9. > > For each NX engine per chip, setup receive window using > vas_rx_win_open() which configures

Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On 18 July 2017 at 06:25, Herbert Xu wrote: > On Tue, Jun 20, 2017 at 11:28:53AM +0200, Ard Biesheuvel wrote: >> The generic AES driver uses 16 lookup tables of 1 KB each, and has >> encryption and decryption routines that are fully unrolled. Given how >> the

Re: [PATCH] crypto: ccp - Fix XTS-AES support on a version 5 CCP

Am Montag, 17. Juli 2017, 22:08:27 CEST schrieb Gary R Hook: Hi Gary, > Version 5 CCPs have differing requirements for XTS-AES: key components > are stored in a 512-bit vector. The context must be little-endian > justified. AES-256 is supported now, so propagate the cipher size to > the command

Re: [PATCH V2 0/6] Enable NX 842 compression engine on Power9

On Mon, 17 Jul 2017 16:43:19 -0700 Haren Myneni wrote: > [PATCH V2 0/6] Enable NX 842 compression engine on Power9 > > P9 introduces Virtual Accelerator Switchboard (VAS) to communicate > with NX 842 engine. icswx function is used to access NX before. > On powerNV

<    1   2