Re: [PATCH v2 2/4] crypto: ccm - switch to separate cbcmac driver

On 28 January 2017 at 23:33, Ard Biesheuvel wrote: > Update the generic CCM driver to defer CBC-MAC processing to a > dedicated CBC-MAC ahash transform rather than open coding this > transform (and much of the associated scatterwalk plumbing) in > the CCM driver itself.

Re: [PATCH v5 2/3] drivers: crypto: Add the Virtual Function driver for CPT

On Mon, Jan 30, 2017 at 7:30 AM, George Cherian wrote: > diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c > b/drivers/crypto/cavium/cpt/cptvf_main.c > new file mode 100644 > index 000..4cf466d > --- /dev/null > +++ b/drivers/crypto/cavium/cpt/cptvf_main.c > @@

Re: [PATCH] crypto: ccp: Fix double add when creating new DMA command

On 01/27/2017 05:09 PM, Gary R Hook wrote: Eliminate a double-add by creating a new list to manage command descriptors when created; move the descriptor to the pending list when the command is submitted. Herbert, Another patch that could use some 4.10 love. Possible? Thanks, Gary

Re: [PATCH] crypto: ccp: Fix DMA operations when IOMMU is enabled

On 01/27/2017 03:28 PM, Gary R Hook wrote: An I/O page fault occurs when the IOMMU is enabled on a system that supports the v5 CCP. DMA operations use a Request ID value that does not match what is expected by the IOMMU, resulting in the I/O page fault. Setting the Request ID value to 0

Re: [PATCH] crypto: arm64/crc32 - merge CRC32 and PMULL instruction based drivers

On 02/01/2017 04:35 PM, Ard Biesheuvel wrote: The PMULL based CRC32 implementation already contains code based on the separate, optional CRC32 instructions to fallback to when operating on small quantities of data. We can expose these routines directly on systems that lack the 64x64 PMULL

[PATCH v3] crypto: aes - add generic time invariant AES cipher

Lookup table based AES is sensitive to timing attacks, which is due to the fact that such table lookups are data dependent, and the fact that 8 KB worth of tables covers a significant number of cachelines on any architecture, resulting in an exploitable correlation between the key and the

Re: crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2

On Thu, 2017-02-02 at 11:58 +0100, Dmitry Vyukov wrote: > On Wed, Feb 1, 2017 at 7:45 PM, Tim Chen wrote: > > > > On Tue, Jan 31, 2017 at 02:16:31PM +0100, Dmitry Vyukov wrote: > > > > > > Hello, > > > > > > I am getting the following reports with low frequency

[PATCH] crypto: generic/aes - drop alignment requirement

The generic AES code exposes a 32-bit align mask, which forces all users of the code to use temporary buffers or take other measures to ensure the alignment requirement is adhered to, even on architectures that don't care about alignment for software algorithms such as this one. So drop the align

[PATCH v2] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

Instead of unconditionally forcing 4 byte alignment for all generic chaining modes that rely on crypto_xor() or crypto_inc() (which may result in unnecessary copying of data when the underlying hardware can perform unaligned accesses efficiently), make those functions deal with unaligned input

Re: [PATCH v3 2/3] crypto: brcm: Add Broadcom SPU driver

Herbert, > On Feb 2, 2017, at 9:05 AM, Herbert Xu wrote: > > On Wed, Jan 25, 2017 at 11:44:48AM -0500, Rob Rice wrote: >> >> +static int ahash_export(struct ahash_request *req, void *out) >> +{ >> +const struct iproc_reqctx_s *rctx = ahash_request_ctx(req); >>

Re: [PATCH v3 2/3] crypto: brcm: Add Broadcom SPU driver

On Wed, Jan 25, 2017 at 11:44:48AM -0500, Rob Rice wrote: > > +static int ahash_export(struct ahash_request *req, void *out) > +{ > + const struct iproc_reqctx_s *rctx = ahash_request_ctx(req); > + > + memcpy(out, rctx, offsetof(struct iproc_reqctx_s, msg_buf)); > + return 0; > +} The

Re: [PATCH 0/6] Add support for ECDSA algorithm

On Thu, Jan 26, 2017 at 11:30:04AM +0530, Nitin Kumbhar wrote: > > This ECDSA implementation is analogous to the RSA kernel implementation for > signature generation / verification. It extends ECC family of algorithms > like ECDH to support signature verification using akcipher. This will be >

Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out

On 2 February 2017 at 09:53, Herbert Xu wrote: > On Thu, Feb 02, 2017 at 08:01:47AM +, Ard Biesheuvel wrote: >> >> You are right: due to its construction, the CCM mode does not care >> about the incremented counter because it clears the counter part of >> the IV

[PATCH 2/2] crypto: arm/aes - don't use IV buffer to return final keystream block

The ARM bit sliced AES core code uses the IV buffer to pass the final keystream block back to the glue code if the input is not a multiple of the block size, so that the asm code does not have to deal with anything except 16 byte blocks. This is done under the assumption that the outgoing IV is

[PATCH 1/2] crypto: arm64/aes - don't use IV buffer to return final keystream block

The arm64 bit sliced AES core code uses the IV buffer to pass the final keystream block back to the glue code if the input is not a multiple of the block size, so that the asm code does not have to deal with anything except 16 byte blocks. This is done under the assumption that the outgoing IV is

Re: crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2

On Wed, Feb 1, 2017 at 7:45 PM, Tim Chen wrote: > On Tue, Jan 31, 2017 at 02:16:31PM +0100, Dmitry Vyukov wrote: >> Hello, >> >> I am getting the following reports with low frequency while running >> syzkaller fuzzer. Unfortunately they are not reproducible and happen

Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out

On Thu, Feb 02, 2017 at 08:01:47AM +, Ard Biesheuvel wrote: > > You are right: due to its construction, the CCM mode does not care > about the incremented counter because it clears the counter part of > the IV before encrypting the MAC. So this is caused by an optimization > in my code rather

Re: [PATCH -stable] crypto: ccm - deal with CTR ciphers that honour iv_out

On 2 February 2017 at 05:13, Herbert Xu wrote: > On Wed, Feb 01, 2017 at 08:08:09PM +, Ard Biesheuvel wrote: >> >> Could you please forward this patch to Linus as well? I noticed that the >> patch > > Sure, I will do that. > >> crypto: arm64/aes-blk - honour