[PATCH 6/7] crypto: aesni: make AVX2 AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S index

[PATCH 5/7] crypto: aesni: make AVX2 AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 85

[PATCH 0/7] crypto: aesni: provide generic gcm(aes)

The current aesni AES-GCM implementation only offers support for rfc4106(gcm(aes)). This makes some things a little bit simpler (handling of associated data and authentication tag), but it means that non-IPsec users of gcm(aes) have to rely on gcm_base(ctr-aes-aesni,ghash-clmulni), which is much

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote: > > > On 28/04/17 12:30 AM, Herbert Xu wrote: > > You are right. Indeed the existing code looks buggy as they > > don't take sg->offset into account when doing the kmap. Could > > you send me some patches that fix these problems

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 28/04/17 12:30 AM, Herbert Xu wrote: > You are right. Indeed the existing code looks buggy as they > don't take sg->offset into account when doing the kmap. Could > you send me some patches that fix these problems first so that > they can be easily backported? Ok, I think the only buggy

[PATCH 3/7] crypto: aesni: make AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 122

[PATCH 7/7] crypto: aesni: add generic gcm(aes)

Now that the asm side of things can support all the valid lengths of ICV and all lengths of associated data, provide the glue code to expose a generic gcm(aes) crypto algorithm. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_glue.c | 208

[PATCH 2/7] crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_asm.S | 62 ++- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index

[PATCH 4/7] crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S index

[PATCH 1/7] crypto: aesni: make non-AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_asm.S | 169

[PATCH] crypto: hifn_795x: Fix a handful of minor bugs spotted by eye

* Cleaned up the formatting of ablkcipher_get arguments so it complies with kernel style * The offset in ablkcipher_get sould be added to the source, not the destination. We rename it to soffset for clarity. * dst++ should be dst=sg_next(dst) * We call kunmap_atomic earlier so we only have to

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 28/04/17 11:51 AM, Herbert Xu wrote: > On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote: >> >> >> On 28/04/17 12:30 AM, Herbert Xu wrote: >>> You are right. Indeed the existing code looks buggy as they >>> don't take sg->offset into account when doing the kmap. Could >>> you

Re: [PATCH] crypto: talitos: Extend max key length for SHA384/512-HMAC

On 4/27/2017 6:46 PM, Martin Hicks wrote: > > The max keysize for both of these is 128, not 96. Before, with keysizes > over 96, the memcpy in ahash_setkey() would overwrite memory beyond the > key field. > While here, what about aead_setkey()? AFAICT, TALITOS_MAX_KEY_SIZE value has been

Re: [PATCH 0/5] KEYS: fixes for new keyctl_dh_compute() KDF extension

Stephan, Eric Biggers wrote: > This patch series fixes several bugs in the KDF extension to > keyctl_dh_compute() currently sitting in keys-next: a way userspace could > cause an infinite loop, two ways userspace could cause the use of > uninitialized memory, a

Re: [PATCH 0/5] KEYS: fixes for new keyctl_dh_compute() KDF extension

Am Freitag, 28. April 2017, 17:53:00 CEST schrieb David Howells: Hi David, > Stephan, > > Eric Biggers wrote: > > This patch series fixes several bugs in the KDF extension to > > keyctl_dh_compute() currently sitting in keys-next: a way userspace could > > cause an

[no subject]

внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 09:45:57AM -0600, Logan Gunthorpe wrote: > > > On 26/04/17 09:56 PM, Herbert Xu wrote: > > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: > >> Very straightforward conversion to the new function in the caam driver > >> and shash library. > >> > >>