Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hello, On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote: > Hannes Frederic Sowa wrote: > > On 24.12.2016 00:39, George Spelvin wrote: > > > We just finished discussing why 8 bytes isn't enough. If you only > > > feed back 8 bytes, an attacker who can do 2^64 computation can find it > > >

[PATCH 4/8] random: remove unused branch in hot code path

The variable ip is defined to be a __u64 which is always 8 bytes on any architecture. Thus, the check for sizeof(ip) > 4 will always be true. As the check happens in a hot code path, remove the branch. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 3 +-- 1

[PATCH 1/8] random: remove stale maybe_reseed_primary_crng

>From 5e84a71d4c4b3c7f015878c0907102634603d270 Mon Sep 17 00:00:00 2001 From: Stephan Mueller Date: Thu, 15 Dec 2016 12:42:33 +0100 Subject: The function maybe_reseed_primary_crng is not used anywhere and thus can be removed. Besides, it contains the check crng_init >

[PATCH 6/8] random: fix comment for unused random_min_urandom_seed

The variable random_min_urandom_seed is not needed any more as it defined the reseeding behavior of the nonblocking pool. Though it is not needed any more, it is left in the code for user space interface compatibility. Signed-off-by: Stephan Mueller ---

[PATCH 0/8] random: cleanup of code after removal of nonblocking pool

Hi Ted, with the removal of the nonblocking_pool, several code paths are now unused which were only applicable to the nonblocking pool. This patch set removes these unused code paths. Also, a code path in the add_interrupt_randomness function that is never used is removed. In addition, the FIPS

[PATCH 5/8] random: remove variable limit

The variable limit was used to identify the nonblocking pool's unlimited random number generation. As the nonblocking pool is a thing of the past, remove the limit variable and any conditions around it (i.e. preserve the branches for limit == 1). Signed-off-by: Stephan Mueller

[PATCH 3/8] random: trigger random_ready callback upon crng_init == 1

The random_ready callback mechanism is intended to replicate the getrandom system call behavior to in-kernel users. As the getrandom system call unblocks with crng_init == 1, trigger the random_ready wakeup call at the same time. Signed-off-by: Stephan Mueller ---

[PATCH 2/8] random: remove stale urandom_init_wait

The urandom_init_wait wait queue is a left over from the pre-ChaCha20 times and can therefore be savely removed. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index

[PATCH 8/8] random: move FIPS continuous test to output functions

The current lockation of the FIPS continuous self test covers the input_pool only. However, the FIPS continuous self test shall cover the output of the random number generator, i.e. the blocking pool and the ChaCha20 DRNG. This patch therefore moves the continuous test to the output function used

[PATCH 7/8] random: remove noop function call to xfer_secondary_pool

Since the introduction of the ChaCha20 DRNG, extract_entropy is only invoked with the input_pool. For this entropy pool, xfer_secondary_pool is a no-op and can therefore be safely removed. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 1 - 1 file changed, 1

Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20

On 27 December 2016 at 15:36, Jeffrey Walton wrote: >> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be >> an efficient software implementable 'standby cipher', in case AES cannot >> be used. > > That's not quite correct. > > The IETF changed the

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Tue, Dec 27, 2016 at 6:16 AM, Daniel Borkmann wrote: > On 12/27/2016 10:58 AM, Herbert Xu wrote: >> >> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: >>> >>> >>> According to Daniel, the networking folks want to let embedded systems >>> include BPF

Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can

On 27 December 2016 at 08:57, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 01:47:26PM +, Ard Biesheuvel wrote: >> The bit-sliced NEON implementation of AES only performs optimally if >> it can process 8 blocks of input in parallel. This is due to the nature >> of

Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20

> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be > an efficient software implementable 'standby cipher', in case AES cannot > be used. That's not quite correct. The IETF changed the algorithm a bit, and its not compatible with Bernstein's ChaCha. They probably should

Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20

> On 27 Dec 2016, at 10:04, Herbert Xu wrote: > >> On Thu, Dec 08, 2016 at 02:28:57PM +, Ard Biesheuvel wrote: >> Another port of existing x86 SSE code to NEON, again both for arm64 and ARM. >> >> ChaCha20 is a stream cipher described in RFC 7539, and is

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On 12/27/2016 10:58 AM, Herbert Xu wrote: On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: According to Daniel, the networking folks want to let embedded systems include BPF without requiring the crypto core. Last I checked the IPv4 stack depended on the crypto API so this

Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver

Hi Herbert, Thanks for your response >Hi Jan: On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote: > > > >this series adds support for hardware accelerated compression & decompression > >as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally > >for some time and

[cryptodev:master 4/17] arch/arm/crypto/chacha20-neon-glue.c:68:32: error: passing argument 1 of 'crypto_chacha20_crypt' from incompatible pointer type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: fb91a661d99f460f2ea4c7f23ed47f56863ca1d1 commit: 9ae433bc79f97bae221d53bb1a8e21415ea58625 [4/17] crypto: chacha20 - convert generic and x86 versions to skcipher config: arm-allmodconfig (attached as

[cryptodev:master 4/17] arch/arm64/crypto/chacha20-neon-glue.c:66:32: error: passing argument 1 of 'crypto_chacha20_crypt' from incompatible pointer type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: fb91a661d99f460f2ea4c7f23ed47f56863ca1d1 commit: 9ae433bc79f97bae221d53bb1a8e21415ea58625 [4/17] crypto: chacha20 - convert generic and x86 versions to skcipher config: arm64-allmodconfig (attached

Re: [PATCHv2] crypto: testmgr: Use heap buffer for acomp test input

On Wed, Dec 21, 2016 at 12:32:54PM -0800, Laura Abbott wrote: > > Christopher Covington reported a crash on aarch64 on recent Fedora > kernels: > > kernel BUG at ./include/linux/scatterlist.h:140! > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > Modules linked in: > CPU: 2 PID: 752 Comm:

Re: [PATCH v3 0/2] Add MediaTek crypto accelerator driver

On Mon, Dec 19, 2016 at 10:20:43AM +0800, Ryder Lee wrote: > Hello, > > This adds support for the MediaTek hardware accelerator on > some SoCs. > > This driver currently implement: > - SHA1 and SHA2 family(HMAC) hash algorithms. > - AES block cipher in CBC/ECB mode with 128/196/256 bits keys. >

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

On Thu, Dec 15, 2016 at 02:31:01PM +0100, Jiri Slaby wrote: > With this reproducer: > struct sockaddr_alg alg = { > .salg_family = 0x26, > .salg_type = "hash", > .salg_feat = 0xf, > .salg_mask = 0x5, > .salg_name = "digest_null", > }; > int

Re: [PATCH v2 1/7] hwrng: core: do not use multiple blank lines

On Tue, Dec 13, 2016 at 03:51:09PM +0100, Corentin Labbe wrote: > This patch fix the checkpatch warning "Please don't use multiple blank lines" > > Signed-off-by: Corentin Labbe Patches 1-6 applied. Thanks. -- Email: Herbert Xu Home

Re: [PATCH] crypto: aesni-intel - RFC4106 can zero copy when !PageHighMem

On Tue, Dec 13, 2016 at 04:32:06PM +0200, Ilya Lesokhin wrote: > In the common case of !PageHighMem we can do zero copy crypto > even if sg crosses a pages boundary. > > Signed-off-by: Ilya Lesokhin Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher

On Fri, Dec 09, 2016 at 02:33:51PM +, Ard Biesheuvel wrote: > This converts the ChaCha20 code from a blkcipher to a skcipher, which > is now the preferred way to implement symmetric block and stream ciphers. > > This ports the generic and x86 versions at the same time because the > latter

Re: [PATCH] crypto: bring back alphabetical order of Makefile

On Tue, Dec 13, 2016 at 03:30:59PM +0100, Corentin Labbe wrote: > THe major content of drivers/crypto/Makefile is sorted, only recent > addition break this sort. > > This patch bring back this alphabetical sorting. > > Signed-off-by: Corentin Labbe Patch applied.

Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20

On Thu, Dec 08, 2016 at 02:28:57PM +, Ard Biesheuvel wrote: > Another port of existing x86 SSE code to NEON, again both for arm64 and ARM. > > ChaCha20 is a stream cipher described in RFC 7539, and is intended to be > an efficient software implementable 'standby cipher', in case AES cannot >

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote: > > According to Daniel, the networking folks want to let embedded systems > include BPF without requiring the crypto core. Last I checked the IPv4 stack depended on the crypto API so this sounds bogus. Cheers, -- Email: Herbert

Re: [sparc64] cryptomgr_test OOPS kernel 4.9.0+

On Mon, Dec 26, 2016 at 05:26:19PM -0500, David Miller wrote: > From: Anatoly Pugachev > Date: Sun, 25 Dec 2016 20:56:08 +0300 > > > Disabling kernel config option > > CRYPTO_MANAGER_DISABLE_TESTS > > i.e. enable run-time self tests, makes kernel unbootable: > > > > tested

Crypto Fixes for 4.10

Hi Linus: This push fixes a hash corruption bug in the marvell driver. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Romain Perier (1): crypto: marvell - Copy IVDIG before launching partial DMA ahash requests drivers/crypto/marvell/cesa.h

Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver

Hi Jan: On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote: > > this series adds support for hardware accelerated compression & decompression > as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally > for some time and would like to get feedback on the RFC to see

Re: [PATCH v2 7/7] hwrng: core: Remove linux/sched.h from includes

On Tue, Dec 13, 2016 at 03:51:15PM +0100, Corentin Labbe wrote: > linux/sched.h is useless for hw_random/core.c. > This patch remove it. I see a schedule_timeout_interruptible call in core.c. Cheers, -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto: arm64/aes: reimplement bit-sliced ARM/NEON implementation for arm64

On Mon, Dec 12, 2016 at 05:45:58PM +, Ard Biesheuvel wrote: > > + .chunksize = 8 * AES_BLOCK_SIZE, Same comment as to the previous patches regarding chunksize. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP

Re: [PATCH v2 2/3] crypto: arm64/chacha20 - implement NEON version based on SSE3 code

On Fri, Dec 09, 2016 at 02:33:52PM +, Ard Biesheuvel wrote: > > + .chunksize = 4 * CHACHA20_BLOCK_SIZE, This should use a new attribute specific to the walk interface. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/

Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can

On Fri, Dec 09, 2016 at 01:47:26PM +, Ard Biesheuvel wrote: > The bit-sliced NEON implementation of AES only performs optimally if > it can process 8 blocks of input in parallel. This is due to the nature > of bit slicing, where the n-th bit of each byte of AES state of each input > block is