Re: IV generation in cryptographic driver in AEAD

Denis B wrote: > Forgive my dumbness, but in: > > .cra_type = _aead_type, > .cra_u = { >.aead = { >.setkey = pp_crypto_aead_setkey, >.setauthsize = pp_crypto_aead_setauthsize, >.decrypt =

Re: IV generation in cryptographic driver in AEAD

Am Mittwoch, 18. Mai 2016, 15:06:19 schrieb Denis B: Hi Denis, > Hello, > > In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel > versions prior to 4.2 the cryptographic driver is expected to generate > an IV. The driver is not expected to generate the IV. Please see the ASCII

Re: Typos and RSA

On 05/18/2016 08:57 AM, Gary R Hook wrote: > Yes, thank you. After spending more time wandering through rsa.c & > rsa_helper.c > I have come to realize that I have been laboring under a paradigm imposed by > my implementation requirements. Now that I have that cleared up, the answer to > my

Re: Typos and RSA

Ah enlightenment can be such an uncomfortable thing... On 05/17/2016 05:56 PM, Stephan Mueller wrote: Am Dienstag, 17. Mai 2016, 17:46:44 schrieb Gary R Hook: Hi Gary, Thanks so much. There are exactly 3 references to that symbol (in my freshly pulled copy of cryptodev-2.6). testmgr.c

[PATCH v2] crypto: public_key: select CRYPTO_AKCIPHER

In some rare randconfig builds, we can end up with ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled, which fails to link because of the reference to crypto_alloc_akcipher: crypto/built-in.o: In function `public_key_verify_signature': :(.text+0x110e4): undefined reference to

Re: [PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

On Wednesday 18 May 2016 22:50:31 Herbert Xu wrote: > On Wed, May 18, 2016 at 04:12:44PM +0200, Arnd Bergmann wrote: > > In some rare randconfig builds, we can end up with > > ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, > > which fails to link because of the reference to

Re: [PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

On Wed, May 18, 2016 at 04:12:44PM +0200, Arnd Bergmann wrote: > In some rare randconfig builds, we can end up with > ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, > which fails to link because of the reference to crypto_alloc_akcipher: This symbol is not meant to be

Re: IV generation in cryptographic driver in AEAD

Forgive my dumbness, but in: .cra_type = _aead_type, .cra_u = { .aead = { .setkey = pp_crypto_aead_setkey, .setauthsize = pp_crypto_aead_setauthsize, .decrypt = pp_crypto_aead_dec, .encrypt =

Re: IV generation in cryptographic driver in AEAD

Inline comments. From: linux-crypto-ow...@vger.kernel.org on behalf of Denis B Sent: Wednesday, May 18, 2016 3:06 PM To: linux-crypto@vger.kernel.org Subject: IV generation in cryptographic

[PATCH] crypto: public_key: select CRYPTO_AKCIPHER2

In some rare randconfig builds, we can end up with ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER2 disabled, which fails to link because of the reference to crypto_alloc_akcipher: crypto/built-in.o: In function `public_key_verify_signature': :(.text+0x110e4): undefined reference to

IV generation in cryptographic driver in AEAD

Hello, In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel versions prior to 4.2 the cryptographic driver is expected to generate an IV. What if my driver is unable to generate an IV? Thanks, Dennis. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in

Re: [patch] crypto: omap-sham - potential Oops on error in probe

On 05/18/16 14:44, Dan Carpenter wrote: > On Wed, May 18, 2016 at 01:42:36PM +0300, Peter Ujfalusi wrote: >> On 05/18/16 13:39, Dan Carpenter wrote: >>> This if statement is reversed so we end up either leaking or Oopsing on >>> error. >> >> Oops, sorry for that. >> Probably the other omap-*

Re: [patch] crypto: omap-sham - potential Oops on error in probe

On Wed, May 18, 2016 at 01:42:36PM +0300, Peter Ujfalusi wrote: > On 05/18/16 13:39, Dan Carpenter wrote: > > This if statement is reversed so we end up either leaking or Oopsing on > > error. > > Oops, sorry for that. > Probably the other omap-* crypto drivers have the same issue? Can you send a

Re: Decrypting data in RX path

Am Mittwoch, 18. Mai 2016, 07:01:18 schrieb Catalin Vasile: Hi Catalin, > Inline Comments > > From: linux-crypto-ow...@vger.kernel.org > on behalf of Gadre Nayan > Sent: Monday, May 16, 2016 5:40

Re: [patch] crypto: omap-sham - potential Oops on error in probe

On 05/18/16 13:39, Dan Carpenter wrote: > This if statement is reversed so we end up either leaking or Oopsing on > error. Oops, sorry for that. Probably the other omap-* crypto drivers have the same issue? Can you send a patch for them or should I do it? Acked-by: Peter Ujfalusi

[patch] crypto: omap-sham - potential Oops on error in probe

This if statement is reversed so we end up either leaking or Oopsing on error. Fixes: dbe246209bc1 ('crypto: omap-sham - Use dma_request_chan() for requesting DMA channel') Signed-off-by: Dan Carpenter diff --git a/drivers/crypto/omap-sham.c

[PATCH 0/2] crypto: engine: permit to enqueue ashash_request

Hello I wanted to use the crypto engine for my Allwinner crypto driver but something prevented me to use it: it cannot enqueue hash requests. The first patch convert crypto engine to permit enqueuing of ahash_requests. The second patch convert the only driver using crypto engine. The second

[PATCH 2/2] crypto: omap: convert to the new cryptoengine API

Since the crypto engine has been converted to use crypto_async_request instead of ablkcipher_request, minor changes are needed to use it. Signed-off-by: LABBE Corentin --- drivers/crypto/omap-aes.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff

[PATCH 1/2] crypto: engine: permit to enqueue ashash_request

The current crypto engine allow only ablkcipher_request to be enqueued. Thus denying any use of it for hardware that also handle hash algo. This patch convert all ablkcipher_request references to the more general crypto_async_request. Signed-off-by: LABBE Corentin ---

Re: Decrypting data in RX path

Inline Comments From: linux-crypto-ow...@vger.kernel.org on behalf of Gadre Nayan Sent: Monday, May 16, 2016 5:40 PM To: Stephan Mueller; linux-crypto@vger.kernel.org Subject: Re: Decrypting data

Re: linux-4.6/drivers/crypto/ux500/hash/hash_core.c: 2 * possible bad size ?

On Mon, May 16, 2016 at 07:13:12PM +0100, David Binderman wrote: > Hello there, > > 1. > > linux-4.6/drivers/crypto/ux500/hash/hash_core.c:784]: (warning) Division by > result of sizeof(). memmove() expects a size in bytes, did you intend to > multiply instead? > > Source code is > >