On Wed, Feb 7, 2018 at 7:09 PM, Eric Biggers wrote:
> Hello,
>
> This series adds Speck support to the crypto API, including the Speck128
> and Speck64 variants. Speck is a lightweight block cipher that can be
> much faster than AES on processors that don't have AES instructions.
>
> We are plann
Add test vectors for Speck128-XTS, generated in userspace using C code.
The inputs were borrowed from the AES-XTS test vectors.
Both xts(speck128-generic) and xts-speck128-neon pass these tests.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 9 +
crypto/testmgr.h | 687 +++
Add test vectors for Speck64-XTS, generated in userspace using C code.
The inputs were borrowed from the AES-XTS test vectors, with key lengths
adjusted.
xts-speck64-neon passes these tests. However, they aren't currently
applicable for the generic XTS template, as that only supports a 128-bit
bl
Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
Speck64. Each 128-byte chunk goes through XTS preprocessing, then is
encrypted/decrypted (doing one cipher round for all the blocks, then the
next round,
Export the Speck constants and transform context and the ->setkey(),
->encrypt(), and ->decrypt() functions so that they can be reused by the
ARM NEON implementation of Speck-XTS. The generic key expansion code
will be reused because it is not performance-critical and is not
vectorizable, while th
Add a generic implementation of Speck, including the Speck128 and
Speck64 variants. Speck is a lightweight block cipher that can be much
faster than AES on processors that don't have AES instructions.
We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
option for dm-crypt and fsc
Hello,
This series adds Speck support to the crypto API, including the Speck128
and Speck64 variants. Speck is a lightweight block cipher that can be
much faster than AES on processors that don't have AES instructions.
We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
option f
Am Mittwoch, 7. Februar 2018, 17:14:12 CET schrieb Jonathan Cameron:
Hi Jonathan,
> Actually those were fine on the basis that inline iv is
> obvious enough, it was CRYPTO_TFM_REQ_PARALLEL that
> was causing me confusion.
>
> Sorry, wasn't terribly clear on that!
Ok, I will add some comments ar
On Wed, 7 Feb 2018 16:43:10 +0100
Stephan Mueller wrote:
> Am Mittwoch, 7. Februar 2018, 16:39:11 CET schrieb Jonathan Cameron:
>
> Hi Jonathan,
>
> > On Wed, 7 Feb 2018 13:48:32 +0100
> >
> > Stephan Mueller wrote:
> > > Am Mittwoch, 7. Februar 2018, 08:44:04 CET schrieb Stephan Müller:
>
In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
Signed-off-by: Kamil Konieczny
Reported-by: Anand Moon
Reviewed-by: Krzysztof Kozlowski
Tested-by: Anand Moon
Cc: sta...@vger.kernel.org # can be applied after commit 8f9702
Am Mittwoch, 7. Februar 2018, 16:39:11 CET schrieb Jonathan Cameron:
Hi Jonathan,
> On Wed, 7 Feb 2018 13:48:32 +0100
>
> Stephan Mueller wrote:
> > Am Mittwoch, 7. Februar 2018, 08:44:04 CET schrieb Stephan Müller:
> >
> > Hi,
> >
> > > diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
On Wed, 7 Feb 2018 13:48:32 +0100
Stephan Mueller wrote:
> Am Mittwoch, 7. Februar 2018, 08:44:04 CET schrieb Stephan Müller:
>
> Hi,
>
>
> > diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> > index 3970ad7f6fd0..da010405eea0 100644
> > --- a/crypto/algif_aead.c
> > +++ b/crypto/algif_
On Wed, 7 Feb 2018 08:42:59 +0100
Stephan Müller wrote:
> Hi Herbert,
>
> Herbert, the patch 1 is meant for stable. However, this patch as is
> only applies to the new AF_ALG interface implementation. Though,
> the issue goes back to the first implementation of AIO support.
> Shall I try prepare
On 10/6/2017 4:06 PM, Christophe Leroy wrote:
> At every request, we map and unmap the same hash hw_context.
>
> This patch moves the dma mapping/unmapping in functions ahash_init()
> and ahash_import().
>
> Signed-off-by: Christophe Leroy
> ---
> drivers/crypto/talitos.c | 80
> ++
Am Mittwoch, 7. Februar 2018, 14:54:08 CET schrieb Jonathan Cameron:
Hi Jonathan,
>
> It's not a 'bug' as such, but this does currently break the crypto-perf
> test for aio and iiv in the libkcapi branch. We can perhaps make it
> more forgiving...
I just pushed an update for the IIV branch of
On Wed, 7 Feb 2018 08:43:32 +0100
Stephan Müller wrote:
> The kernel crypto API requires the caller to set an IV in the request
> data structure. That request data structure shall define one particular
> cipher operation. During the cipher operation, the IV is read by the
> cipher implementation
On Wed, Feb 07, 2018 at 11:52:01AM +0100, Artem Savkov wrote:
> On Wed, Feb 07, 2018 at 10:56:59AM +0100, Corentin Labbe wrote:
> > On Tue, Feb 06, 2018 at 10:20:21PM +0100, Artem Savkov wrote:
> > > According to crypto/rng.h generate function should return 0 on success
> > > and < 0 on error.
> >
This patchset depends on "crypto: engine - Permit to enqueue all async requests"
proposed by Corentin Labbe [https://lkml.org/lkml/2018/1/26/608].
stm32-cryp uses this updated crpyto engine to handle AEAD cipher algortihms.
Fabien Dessenne (2):
crypto: stm32/cryp - add aes gcm / ccm support
cr
Add AEAD cipher algorithms for aes gcm and ccm.
Signed-off-by: Fabien Dessenne
---
drivers/crypto/stm32/stm32-cryp.c | 931 --
1 file changed, 902 insertions(+), 29 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-cryp.c
b/drivers/crypto/stm32/stm32-cryp
stm32mp1 differs from stm32f7 in the way it handles byte ordering and
padding for aes gcm & ccm algo.
Signed-off-by: Fabien Dessenne
---
drivers/crypto/stm32/stm32-cryp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/stm32/stm32-cryp.c
b/drivers/crypto/stm32/stm32-cry
Am Mittwoch, 7. Februar 2018, 08:44:04 CET schrieb Stephan Müller:
Hi,
> diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> index 3970ad7f6fd0..da010405eea0 100644
> --- a/crypto/algif_aead.c
> +++ b/crypto/algif_aead.c
> @@ -66,13 +66,22 @@ static int aead_sendmsg(struct socket *sock, str
On Wed, Feb 07, 2018 at 10:56:59AM +0100, Corentin Labbe wrote:
> On Tue, Feb 06, 2018 at 10:20:21PM +0100, Artem Savkov wrote:
> > According to crypto/rng.h generate function should return 0 on success
> > and < 0 on error.
> >
> > Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security Sys
In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
Signed-off-by: Kamil Konieczny
Reported-by: Anand Moon
Reviewed-by: Krzysztof Kozlowski
Tested-by: Anand Moon
Cc: sta...@vger.kernel.org
Fixes: 8f9702aad138 ("crypto: s5p-ss
On Tue, Feb 06, 2018 at 10:20:21PM +0100, Artem Savkov wrote:
> According to crypto/rng.h generate function should return 0 on success
> and < 0 on error.
>
> Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security System PRNG")
> Signed-off-by: Artem Savkov
> ---
> drivers/crypto/sunxi-ss
On 07-02-2018 13:12, Stephan Müller wrote:
> Hi Herbert,
>
> Herbert, the patch 1 is meant for stable. However, this patch as is
> only applies to the new AF_ALG interface implementation. Though,
> the issue goes back to the first implementation of AIO support.
> Shall I try prepare a patch for t
25 matches
Mail list logo
