On 4 March 2014 15:53, Herbert Xu wrote:
> On Tue, Mar 04, 2014 at 03:51:11PM +0800, Ard Biesheuvel wrote:
>>
>> Is there anything else required before you can take these patches?
>> Note that the first one should go through the arm64 tree, and may need
>> further review on the arm list as well, b
On Tue, Mar 04, 2014 at 03:51:11PM +0800, Ard Biesheuvel wrote:
>
> Is there anything else required before you can take these patches?
> Note that the first one should go through the arm64 tree, and may need
> further review on the arm list as well, but for the first two, it is
> completely up to
On 4 March 2014 15:46, Herbert Xu wrote:
> On Tue, Mar 04, 2014 at 01:28:37PM +0800, Ard Biesheuvel wrote:
>> I think this is a better approach than the one I proposed before. This time,
>> I have only added a single function specifically for use by aeads:
>>
>> blkcipher_aead_walk_virt_block()
>>
On Tue, Mar 04, 2014 at 01:28:37PM +0800, Ard Biesheuvel wrote:
> I think this is a better approach than the one I proposed before. This time,
> I have only added a single function specifically for use by aeads:
>
> blkcipher_aead_walk_virt_block()
>
> which takes an additional aead param which i
In order to allow other uses of the blkcipher walk API than the blkcipher
algos themselves, this patch copies some of the transform data members to the
walk struct so the transform is only accessed at walk init time.
Signed-off-by: Ard Biesheuvel
---
crypto/blkcipher.c | 67
I think this is a better approach than the one I proposed before. This time,
I have only added a single function specifically for use by aeads:
blkcipher_aead_walk_virt_block()
which takes an additional aead param which is used to get the ivsize, alignmask
and blocksize of the underlying transfor
This adds the function blkcipher_aead_walk_virt_block, which allows the caller
to use the blkcipher walk API to handle the input and output scatterlists.
Signed-off-by: Ard Biesheuvel
---
crypto/blkcipher.c | 14 ++
include/crypto/algapi.h | 4
2 files changed, 18 insertio
This adds support for a synchronous implementation of AES in CCM mode
using ARMv8 Crypto Extensions, using NEON registers q0 - q5.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/Makefile| 1 +
arch/arm64/crypto/Makefile | 12 ++
arch/arm64/crypto/aesce-ccm-core.S | 222 +
When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
per-boot differences.
Signed-off-by: Kees Cook
---
drivers/char/hw_random/core.c |
With the addition of the AVX/AVX2 code, the 128 bit key large buffer cases will
not even be handled by the SSE implementation (except for Westmere & Silvermont
cores).
OTOH, no support for 256 bit really is a pain.
- Tim
-Original Message-
From: Tim Chen [mailto:tim.c.c...@linu
I think this should work.
diff --git a/arch/x86/crypto/aesni-intel_asm.S
b/arch/x86/crypto/aesni-intel_asm.S
index 477e9d7..5855172 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -32,12 +32,23 @@
#include
#include
+/*
+* The following macros are use
On Fri, 2014-02-28 at 17:00 -0600, McCaffrey, Timothy M wrote:
> See comments in part 1.
>
> Signed off by: timothy.mccaff...@unisys.com
>
> diff --git a/arch/x86/crypto/aesni-intel_asm.S
> b/arch/x86/crypto/aesni-intel_asm.S
> index 477e9d7..5855172 100644
> --- a/arch/x86/crypto/aesni-intel_as
On Fri, 2014-02-28 at 17:00 -0600, McCaffrey, Timothy M wrote:
> These patches fix the RFC4106 implementation in the aesni-intel module so it
> supports 192 & 256 bit keys.
> Since AVX was recently added to this module, and this patch only affects the
> SSE implementation, changes
> were also ma
Optimize the hashing operation in the MXS-DCP by doing two adjustments:
1) Given that the output buffer for the hash is now always correctly aligned,
we can just use the buffer for the DCP DMA to store the resulting hash.
We thus get rid of one copying of data. Moreover, we remove an entry fr
14 matches
Mail list logo
