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.
>
> This cleans up the code
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
> @@ -0,0 +1,948 @@
> +/*
> + * Co
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
Signed-o
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 correct
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 instr
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 processin
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 while running
> > > syzkaller fuz
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
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 expl
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);
>> +
>> +memcpy(out, rctx, o
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
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
> use
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 before encrypting the MAC. So t
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 mea
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 m
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
>> in a background thread, so
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 t
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 iv_out requirement in CBC and CTR
18 matches
Mail list logo
