[PATCH v2 0/4] crypto: CTR DRBG - performance improvements

Hi, The following patch set is aimed to increase the performance of the CTR DRBG, especially when assembler implementations of the CTR AES mode are available. The patch set increases the performance by 10% for random numbers of 16 bytes and reaches 450% for random numbers reaching 4096 bytes

[PATCH v2 2/4] crypto: DRBG - use aligned buffers

Hardware cipher implementation may require aligned buffers. All buffers that potentially are processed with a cipher are now aligned. At the time of the allocation of the memory, we have not yet allocated the cipher implementations. Hence, we cannot obtain the alignmask for the used cipher yet.

[PATCH v2 3/4] crypto: CTR DRBG - use full CTR AES for update

The CTR DRBG update function performs a full CTR AES operation including the XOR with "plaintext" data. Hence, remove the XOR from the code and use the CTR mode to do the XOR. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 30 +- 1 file

[PATCH v2 4/4] crypto: CTR DRBG - avoid duplicate maintenance of key

The TFM object maintains the key for the CTR DRBG. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 8ceb716..ded8638 100644 --- a/crypto/drbg.c +++ b/crypto/drbg.c @@

[PATCH v2 1/4] crypto: CTR DRBG - use CTR AES instead of ECB AES

The CTR DRBG derives its random data from the CTR that is encrypted with AES. This patch now changes the CTR DRBG implementation such that the CTR AES mode is employed. This allows the use of steamlined CTR AES implementation such as ctr-aes-aesni. Unfortunately there are the following subtile

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 00:16:11 schrieb Andrew Zaborowski: Hi Andrew, > Hi, > > On 8 June 2016 at 21:14, Mat Martineau > > wrote: > > On Wed, 8 Jun 2016, Stephan Mueller wrote: > >> What is your concern? > > > > Userspace must allocate larger buffers

Re: [PATCH v2 3/3] ARM64: dts: meson-gxbb: Add Hardware Random Generator node

On 06/14/2016 12:09 AM, Kevin Hilman wrote: > Hi Neil, > > Neil Armstrong writes: > >> Signed-off-by: Neil Armstrong >> --- >> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git

Re: [PATCH] crypto : async implementation for sha1-mb

On Mon, Jun 13, 2016 at 07:10:26PM +, Dey, Megha wrote: > > > In the current implementation, the inner algorithm is called directly, and > > we use the outer algorithm's callback. We do not use the callback in inner > > algorithm. We are actually calling the child functions directly and the

Re: [PATCH v2 0/3] hw_random: Add Amlogic Meson SoCs Random Generator driver

Hi Herbert, Herbert Xu writes: > On Fri, Jun 10, 2016 at 10:21:52AM +0200, Neil Armstrong wrote: >> Add support for the Amlogic Meson SoCs Hardware Random generator as a >> hw_random char driver. >> The generator is a single 32bit wide register. >> Also adds the

[PATCH v8 2/3] crypto: kpp - Add DH software implementation

* Implement MPI based Diffie-Hellman under kpp API * Test provided uses data generad by OpenSSL Signed-off-by: Salvatore Benedetto --- crypto/Kconfig | 8 ++ crypto/Makefile | 2 + crypto/dh.c | 189

[PATCH v8 1/3] crypto: Key-agreement Protocol Primitives API (KPP)

Add key-agreement protocol primitives (kpp) API which allows to implement primitives required by protocols such as DH and ECDH. The API is composed mainly by the following functions * set_secret() - It allows the user to set his secret, also referred to as his private key, along with the

[PATCH v8 0/3] Key-agreement Protocol Primitives (KPP) API

Hi Herb, the following patchset introduces a new API for abstracting key-agreement protocols such as DH and ECDH. It provides the primitives required for implementing the protocol, thus the name KPP (Key-agreement Protocol Primitives). Regards, Salvatore Changed from v7: * API change: merge

RE: [PATCH] crypto : async implementation for sha1-mb

-Original Message- From: Herbert Xu [mailto:herb...@gondor.apana.org.au] Sent: Monday, June 13, 2016 1:22 AM To: Dey, Megha Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux-crypto@vger.kernel.org; linux-ker...@vger.kernel.org; Yu, Fenghua

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Mon, Jun 13, 2016 at 08:00:33PM +0200, Stephan Mueller wrote: > > 1. The ChaCha20 is seeded with 256 bits (let us assume it is full entropy) > > 2. The ChaCha20 block operation shuffles the 256 bits of entropy over the 512 > bit state -- already here we see that after shuffling, the entropy

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 13. Juni 2016, 11:48:37 schrieb Theodore Ts'o: Hi Theodore, > /* > @@ -1254,15 +1423,26 @@ static ssize_t extract_entropy_user(struct > entropy_store *r, void __user *buf, */ > void get_random_bytes(void *buf, int nbytes) > { > + __u8 tmp[CHACHA20_BLOCK_SIZE]; > + > #if

[PATCH 6/7] random: make /dev/urandom scalable for silly userspace programs

On a system with a 4 socket (NUMA) system where a large number of application threads were all trying to read from /dev/urandom, this can result in the system spending 80% of its time contending on the global urandom spinlock. The application should have used its own PRNG, but let's try to help

[PATCH 3/7] random: add interrupt callback to VMBus IRQ handler

From: Stephan Mueller The Hyper-V Linux Integration Services use the VMBus implementation for communication with the Hypervisor. VMBus registers its own interrupt handler that completely bypasses the common Linux interrupt handling. This implies that the interrupt entropy

[PATCH 1/7] random: initialize the non-blocking pool via add_hwgenerator_randomness()

If we have a hardware RNG and are using the in-kernel rngd, we should use this to initialize the non-blocking pool so that getrandom(2) doesn't block unnecessarily. Cc: sta...@kernel.org Signed-off-by: Theodore Ts'o --- drivers/char/random.c | 16 +++- 1 file changed,

[PATCH 2/7] random: print a warning for the first ten uninitialized random users

Since systemd is consistently using /dev/urandom before it is initialized, we can't see the other potentially dangerous users of /dev/urandom immediately after boot. So print the first ten such complaints instead. Cc: sta...@kernel.org Signed-off-by: Theodore Ts'o ---

[PATCH 4/7] random: properly align get_random_int_hash

From: Eric Biggers get_random_long() reads from the get_random_int_hash array using an unsigned long pointer. For this code to be guaranteed correct on all architectures, the array must be aligned to an unsigned long boundary. Cc: sta...@kernel.org Signed-off-by: Eric

[PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

The CRNG is faster, and we don't pretend to track entropy usage in the CRNG any more. Signed-off-by: Theodore Ts'o --- crypto/chacha20_generic.c | 61 drivers/char/random.c | 374 +- include/crypto/chacha20.h | 1 +

[PATCH 7/7] random: add backtracking protection to the CRNG

Signed-off-by: Theodore Ts'o --- drivers/char/random.c | 54 ++- 1 file changed, 49 insertions(+), 5 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d640865..963a6a9 100644 --- a/drivers/char/random.c

Re: [PATCH v2 0/3] hw_random: Add Amlogic Meson SoCs Random Generator driver

On Fri, Jun 10, 2016 at 10:21:52AM +0200, Neil Armstrong wrote: > Add support for the Amlogic Meson SoCs Hardware Random generator as a > hw_random char driver. > The generator is a single 32bit wide register. > Also adds the Meson GXBB SoC DTSI node and corresponding DT bindings. > > Changes

Re: [PATCH 1/2] crypto: vmx: Fix ABI detection

On Fri, Jun 10, 2016 at 04:47:02PM +1000, Anton Blanchard wrote: > From: Anton Blanchard > > When calling ppc-xlate.pl, we pass it either linux-ppc64 or > linux-ppc64le. The script however was expecting linux64le, a result > of its OpenSSL origins. This means we aren't obeying

Re: [PATCH] crypto: ux500: memmove the right size

On Wed, Jun 08, 2016 at 02:56:39PM +0200, Linus Walleij wrote: > The hash buffer is really HASH_BLOCK_SIZE bytes, someone > must have thought that memmove takes n*u32 words by mistake. > Tests work as good/bad as before after this patch. > > Cc: Joakim Bech > Reported-by:

Re: [PATCH] crypto: qat: Remove deprecated create_workqueue

On Wed, Jun 08, 2016 at 02:47:47AM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > The workqueue device_reset_wq has workitem _data->reset_work per > adf_reset_dev_data. The workqueue pf2vf_resp_wq is a workqueue for > PF2VF responses has workitem

Re: [PATCH 2/4] crypto: DRBG - use aligned buffers

Am Montag, 13. Juni 2016, 17:37:14 schrieb Herbert Xu: Hi Herbert, > On Fri, Jun 10, 2016 at 07:56:57AM +0200, Stephan Mueller wrote: > > Hardware cipher implementation may require aligned buffers. All buffers > > that potentially are processed with a cipher are now aligned. > > > > At the time

Re: [PATCH 2/4] crypto: DRBG - use aligned buffers

On Fri, Jun 10, 2016 at 07:56:57AM +0200, Stephan Mueller wrote: > Hardware cipher implementation may require aligned buffers. All buffers > that potentially are processed with a cipher are now aligned. > > At the time of the allocation of the memory, we have not yet allocated > the cipher

Re: [PATCH v5 1/3] crypto: Key-agreement Protocol Primitives API (KPP)

On Wed, Jun 08, 2016 at 12:45:47PM +0100, Salvatore Benedetto wrote: > > Having said that, are you OK with as far as the interface goes > to only merge set_param and set_key, and keeping the rest as it is? > For the implementation of DH and ECDH I'll merge the two operations > functions into one

Re: [PATCH v6 2/8] crypto: add driver-side scomp interface

On Wed, Jun 08, 2016 at 09:16:52AM +0100, Giovanni Cabiddu wrote: > > +static void *scomp_map(struct scatterlist *sg, unsigned int len, > +gfp_t gfp_flags) > +{ > + void *buf; > + > + if (sg_is_last(sg)) > + return kmap_atomic(sg_page(sg)) + sg->offset;