Re: random.c: LFSR polynomials are not irreducible/primitive

On Mon, Aug 14, 2017 at 10:20:18AM +0200, Stephan Mueller wrote: > Hi Ted, > > drivers/char/random.c contains the following comment: > > """ > * Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and > * Videau in their paper, "The Linux Pseudorandom Number Generator > *

Re: [PATCH v5 05/19] crypto: introduce crypto wait for async op

On Mon, 14 Aug 2017 18:21:15 +0300 Gilad Ben-Yossef wrote: > Invoking a possibly async. crypto op and waiting for completion > while correctly handling backlog processing is a common task > in the crypto API implementation and outside users of it. > > This patch adds a

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Stephan, >> I also would like to have more of those algorithms exposed to userspace, >> and I'd like to make sure the API is a good fit. There was extensive >> discussion of AF_ALG akcipher last year. v8 of the patch set updates the >> implementation but doesn't address the API concerns that

random.c: LFSR polynomials are not irreducible/primitive

Hi Ted, drivers/char/random.c contains the following comment: """ * Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and * Videau in their paper, "The Linux Pseudorandom Number Generator * Revisited" (see: http://eprint.iacr.org/2012/251.pdf). In their * paper, they point out

Crypto Fixes for 4.13

Hi Linus: This push fixes an error path bug in ixp4xx as well as a read overrun in sha1-avx2. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Herbert Xu (1): crypto: ixp4xx - Fix error handling path in 'aead_perform()'

Re: [Freedombox-discuss] Hardware Crypto

Hi, On Sun, Aug 13, 2017 at 8:21 PM, Sandy Harris wrote: > Showing only the key parts of the message: > >> From: John Gilmore > > An exceedingly knowledgeable guy, one we should probably take seriously. >

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Stephan, >>> The first part is clearly where AF_ALG fits and keyctl does not. This is >>> provided with the current patch set. As the keyctl API only handles, well, >>> keys, access to the raw ciphers may not be possible through this API. And >>> let us face it, a lot of user space code shall

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Am Sonntag, 13. August 2017, 10:52:00 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > While I don't have anything to contribute to the choice between > keyctl() vs ALG_IF as interfaces for asymmetric cryptography, I would > like to point out that there is both interest and HW support for > private

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Am Montag, 14. August 2017, 08:26:22 CEST schrieb Marcel Holtmann: Hi Marcel, > > The first part is clearly where AF_ALG fits and keyctl does not. This is > > provided with the current patch set. As the keyctl API only handles, well, > > keys, access to the raw ciphers may not be possible

Re: [PATCH] crypto: caam - properly set IV after {en,de}crypt

Hi, On Thu, Jun 29, 2017 at 1:19 PM, Horia Geantă wrote: > On 6/28/2017 4:42 PM, Horia Geantă wrote: >> On 6/28/2017 4:27 PM, David Gstir wrote: >>> Certain cipher modes like CTS expect the IV (req->info) of >>> ablkcipher_request (or equivalently req->iv of

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Am Freitag, 11. August 2017, 21:43:15 CEST schrieb Mat Martineau: Hi Mat, > > I also would like to have more of those algorithms exposed to userspace, > and I'd like to make sure the API is a good fit. There was extensive > discussion of AF_ALG akcipher last year. v8 of the patch set updates

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Am Freitag, 11. August 2017, 18:02:55 CEST schrieb Marcel Holtmann: Hi Marcel, > > Thanks for the reminder. I have looked at that but I am unsure about > > whether this one covers asym crypto appropriately, too. > > > > The issue is that some hardware may only offer accelerators without a full

[PATCH] crypto: cavium - add release_firmware to all return case

Two return case misses to call release_firmware() and so leak some memory. This patch create a fw_release label (and so a common error path) and use it on all return case. Detected by CoverityScan, CID#1416422 ("Resource Leak") Signed-off-by: Corentin Labbe ---

[PATCH 1/2] crypto/chacha20: fix handling of chunked input

Commit 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 versions to skcipher") ported the existing chacha20 code to use the new skcipher API, and introduced a bug along the way. Unfortunately, the tcrypt tests did not catch the error, and it was only found recently by Tobias. Stefan

[PATCH 2/2] crypto: testmgr - add chunked test cases for chacha20

We failed to catch a bug in the chacha20 code after porting it to the skcipher API. We would have caught it if any chunked tests had been defined, so define some now so we will catch future regressions. Signed-off-by: Ard Biesheuvel --- crypto/testmgr.h | 7 +++ 1

scatterwalk.c: Nullpointer dereference

Dear linux-crypto community, I think I might have run into a bug in crypto/scatterwalk.c: - at the end of scatterwalk_pagedone, sg_next(walk->sg) is fed as an argument to scatterwalk_start(...) - sg_next (lib/scatterlist.c) returns NULL in the case of sg_is_last(sg) - In this case, NULL is being

[PATCH 0/3 v3] crypto: engine - Permit to enqueue skcipher request

Hello The crypto engine could actually only enqueue hash and ablkcipher request. This patch serie permit it to enqueue skcipher requests by adding all necessary functions. Changes since v2 - added two patch for finding request type according to its cra_type Changes since v1 - Aligned to column

[PATCH 3/3] crypto: engine - Permit to enqueue skcipher request

The crypto engine could actually only enqueue hash and ablkcipher request. This patch permit it to enqueue skcipher requets by adding all necessary functions. Signed-off-by: Corentin Labbe --- crypto/crypto_engine.c | 114

[PATCH 2/3] crypto: engine - find request type with cra_type

The current method for finding request type is based on crypto_tfm_alg_type. But in case of skcipher, it is the same than ablkcipher. Using cra_type for this work permits to make the distinction between the two. Signed-off-by: Corentin Labbe ---

[PATCH 1/3] crypto: skcipher - export crypto_skcipher_type2

This patch export crypto_skcipher_type2 like others cra_type Signed-off-by: Corentin Labbe --- crypto/skcipher.c | 3 ++- include/crypto/algapi.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/crypto/skcipher.c b/crypto/skcipher.c index

Re: scatterwalk.c: Nullpointer dereference

Am Montag, 14. August 2017, 14:25:49 CEST schrieb Plauth, Max: Hi Max, > Dear linux-crypto community, > > I think I might have run into a bug in crypto/scatterwalk.c: > - at the end of scatterwalk_pagedone, sg_next(walk->sg) is fed as an > argument to scatterwalk_start(...) - sg_next

Re: [PATCH v5 2/5] lib: Add zstd modules

On Fri, Aug 11, 2017 at 09:20:10AM -0400, Chris Mason wrote: > > > On 08/10/2017 03:25 PM, Hugo Mills wrote: > > On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: > >> On 08/10/2017 04:30 AM, Eric Biggers wrote: > >>> > >>> Theses benchmarks are misleading because they compress the

[PATCH v5 00/19] simplify crypto wait for async op

Many users of kernel async. crypto services have a pattern of starting an async. crypto op and than using a completion to wait for it to end. This patch set simplifies this common use case in two ways: First, by separating the return codes of the case where a request is queued to a backlog due

[PATCH v5 16/19] crypto: talitos: move to generic async completion

The talitos driver starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- drivers/crypto/talitos.c | 38 +- 1 file changed, 5 insertions(+), 33

[PATCH v5 14/19] ima: move to generic async completion

ima starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef Acked-by: Mimi Zohar --- security/integrity/ima/ima_crypto.c | 56

[PATCH v5 13/19] cifs: move to generic async completion

cifs starts an async. crypto op and waits for their completion. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef Acked-by: Pavel Shilovsky --- fs/cifs/smb2ops.c | 30 -- 1 file changed, 4

[PATCH v5 15/19] crypto: tcrypt: move to generic async completion

tcrypt starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- crypto/tcrypt.c | 84 + 1 file changed, 25 insertions(+), 59

[PATCH v5 08/19] crypto: move drbg to generic async completion

DRBG is starting an async. crypto op and waiting for it complete. Move it over to generic code doing the same. The code now also passes CRYPTO_TFM_REQ_MAY_SLEEP flag indicating crypto request memory allocation may use GFP_KERNEL which should be perfectly fine as the code is obviously sleeping for

[PATCH v5 02/19] crypto: ccp: use -EAGAIN for transient busy indication

Replace -EBUSY with -EAGAIN when reporting transient busy indication in the absence of backlog. Signed-off-by: Gilad Ben-Yossef --- drivers/crypto/ccp/ccp-crypto-main.c | 8 +++- drivers/crypto/ccp/ccp-dev.c | 7 +-- 2 files changed, 8 insertions(+), 7

[PATCH v5 01/19] crypto: change transient busy return code to -EAGAIN

The crypto API was using the -EBUSY return value to indicate both a hard failure to submit a crypto operation into a transformation provider when the latter was busy and the backlog mechanism was not enabled as well as a notification that the operation was queued into the backlog when the backlog

[PATCH v5 18/19] crypto: mediatek: move to generic async completion

The mediatek driver starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- drivers/crypto/mediatek/mtk-aes.c | 31 +-- 1 file changed, 5 insertions(+), 26

[PATCH v5 17/19] crypto: qce: move to generic async completion

The qce driver starts several async crypto ops and waits for their completions. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- drivers/crypto/qce/sha.c | 30 -- 1 file changed, 4 insertions(+), 26 deletions(-)

[PATCH v5 19/19] crypto: adapt api sample to use async. op wait

The code sample is waiting for an async. crypto op completion. Adapt sample to use the new generic infrastructure to do the same. This also fixes a possible data coruption bug created by the use of wait_for_completion_interruptible() without dealing correctly with an interrupt aborting the wait

[PATCH v5 10/19] crypto: move testmgr to generic async completion

testmgr is starting async. crypto ops and waiting for them to complete. Move it over to generic code doing the same. This also provides a test of the generic crypto async. wait code. Signed-off-by: Gilad Ben-Yossef --- crypto/testmgr.c | 204

[PATCH v5 12/19] dm: move dm-verity to generic async completion

dm-verity is starting async. crypto ops and waiting for them to complete. Move it over to generic code doing the same. This also fixes a possible data coruption bug created by the use of wait_for_completion_interruptible() without dealing correctly with an interrupt aborting the wait prior to the

[PATCH v5 11/19] fscrypt: move to generic async completion

fscrypt starts several async. crypto ops and waiting for them to complete. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- fs/crypto/crypto.c | 28 fs/crypto/fname.c | 36

[PATCH v5 04/19] crypto: marvell/cesa: remove redundant backlog checks on EBUSY

Now that -EBUSY return code only indicates backlog queueing we can safely remove the now redundant check for the CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned. Signed-off-by: Gilad Ben-Yossef --- drivers/crypto/marvell/cesa.c | 3 +-- drivers/crypto/marvell/cesa.h

[PATCH v5 03/19] crypto: remove redundant backlog checks on EBUSY

Now that -EBUSY return code only indicates backlog queueing we can safely remove the now redundant check for the CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned. Signed-off-by: Gilad Ben-Yossef --- crypto/ahash.c| 12 +++- crypto/cts.c | 6

[PATCH v5 05/19] crypto: introduce crypto wait for async op

Invoking a possibly async. crypto op and waiting for completion while correctly handling backlog processing is a common task in the crypto API implementation and outside users of it. This patch adds a generic implementation for doing so in preparation for using it across the board instead of hand

[PATCH v5 06/19] crypto: move algif to generic async completion

algif starts several async crypto ops and waits for their completion. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef --- crypto/af_alg.c | 27 --- crypto/algif_aead.c | 8 crypto/algif_hash.c |

Re: [PATCH v5 02/19] crypto: ccp: use -EAGAIN for transient busy indication

On 08/14/2017 10:21 AM, Gilad Ben-Yossef wrote: Replace -EBUSY with -EAGAIN when reporting transient busy indication in the absence of backlog. Signed-off-by: Gilad Ben-Yossef Reviewed-by: Gary R Hook --- drivers/crypto/ccp/ccp-crypto-main.c | 8