From: Eric Biggers
Commit f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") made
CRYPTO_CTR stop selecting CRYPTO_SEQIV. This breaks IPsec for most
users since GCM and several other encryption algorithms require "seqiv"
-- and RFC 8221 lists AES-GCM as "MU
From: Eric Biggers
The crypto algorithms selected by the ESP and AH kconfig options are
out-of-date with the guidance of RFC 8221, which lists the legacy
algorithms MD5 and DES as "MUST NOT" be implemented, and some more
modern algorithms like AES-GCM and HMAC-SHA256 as "MUST&
d commit messages (added Acked-by tags, fixed a bad Fixes tag,
added some more explanation to patch 3).
Eric Biggers (3):
esp, ah: consolidate the crypto algorithm selections
esp: select CRYPTO_SEQIV
esp, ah: modernize the crypto algorithm selections
net/ipv4/Kconfig | 34 ++
On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote:
> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset() is currently used for the buffer clearing. However,
> it is entirely possib
On Tue, Jun 16, 2020 at 08:02:58AM +0200, Steffen Klassert wrote:
> On Mon, Jun 15, 2020 at 03:13:15PM -0700, Eric Biggers wrote:
> > This series consolidates and modernizes the lists of crypto algorithms
> > that are selected by the IPsec kconfig options, and adds CRYPTO_SEQIV
On Tue, Jun 16, 2020 at 09:04:44PM +1000, Herbert Xu wrote:
> On Mon, Jun 15, 2020 at 11:50:28AM -0700, Eric Biggers wrote:
> >
> > Wouldn't it make a lot more sense to make skcipher algorithms non-chainable
> > by
> > default, and only opt-in the ones where c
On Tue, Jun 16, 2020 at 11:01:31AM -0400, Mikulas Patocka wrote:
> Introduce a new flag CRYPTO_ALG_ALLOCATES_MEMORY and modify dm-crypt, so
> that it uses only drivers without this flag.
>
> If the flag is set, then the crypto driver allocates memory in its request
> routine. Such drivers are not
On Tue, Jun 16, 2020 at 11:01:58AM -0400, Mikulas Patocka wrote:
> Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
>
> Signed-off-by: Mikulas Patocka
>
> ---
> crypto/adiantum.c |3 ++-
> crypto/authenc.c |5 +++--
> crypto/authencesn.c |
On Tue, Jun 16, 2020 at 11:02:20AM -0400, Mikulas Patocka wrote:
> Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
> allocate memory.
>
> Signed-off-by: Mikulas Patocka
>
> ---
> drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c |8 +-
> drivers/crypto/allwinner/sun8i-ss
On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
> CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
> that sleeps.
>
> Signed-off-by: Mikulas Patocka
I think you need to split this up p
On Tue, Jun 16, 2020 at 02:18:17PM -0400, Mikulas Patocka wrote:
>
>
> On Tue, 16 Jun 2020, Eric Biggers wrote:
>
> > On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> > > Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
&
On Tue, Jun 23, 2020 at 04:40:56PM +1000, Herbert Xu wrote:
> On Tue, Jun 23, 2020 at 11:53:43AM +0530, Naresh Kamboju wrote:
> >
> > Thanks for the investigation.
> > After reverting, two test cases got PASS out of four reported failure cases.
> > ltp-crypto-tests:
> > * af_alg02 - still fai
ret = aes_expandkey(&ctx, key, key_len);
> + if (ret)
> + return ret;
>
> -out:
> - skcipher_request_free(req);
> - crypto_free_skcipher(tfm);
> - return ret;
> + aes_encrypt(&ctx, hkey, input);
> + memzero_explicit(&ctx, sizeof(ctx));
> + return 0;
> }
>
Otherwise this looks good. You can add:
Reviewed-by: Eric Biggers
- Eric
On Fri, Jun 26, 2020 at 12:16:33PM -0400, Mikulas Patocka wrote:
> +/*
> + * Pass these flags down through the crypto API.
> + */
> +#define CRYPTO_ALG_INHERITED_FLAGS (CRYPTO_ALG_ASYNC |
> CRYPTO_ALG_ALLOCATES_MEMORY)
This comment is useless. How about:
/*
* When an algorithm uses another a
On Fri, Jun 26, 2020 at 09:46:17AM -0700, Eric Biggers wrote:
> On Fri, Jun 26, 2020 at 12:16:33PM -0400, Mikulas Patocka wrote:
> > +/*
> > + * Pass these flags down through the crypto API.
> > + */
> > +#define CRYPTO_ALG_INHERITED_FLAGS (CRYPTO_ALG_ASYNC |
>
On Sun, Jun 28, 2020 at 03:04:22PM -0400, Mikulas Patocka wrote:
> > > Index: linux-2.6/crypto/authenc.c
> > > ===
> > > --- linux-2.6.orig/crypto/authenc.c 2020-06-26 17:24:03.566417000
> > > +0200
> > > +++ linux-2.6/crypto/au
On Sun, Jun 28, 2020 at 03:07:49PM -0400, Mikulas Patocka wrote:
>
> > Also, "seqiv" instances can be created without CRYPTO_ALG_ALLOCATES_MEMORY
> > set,
> > despite seqiv_aead_encrypt() allocating memory.
> >
This comment wasn't addressed.
- Eric
On Sun, Jun 28, 2020 at 03:07:49PM -0400, Mikulas Patocka wrote:
> >
> > cryptd_create_skcipher(), cryptd_create_hash(), cryptd_create_aead(), and
> > crypto_rfc4309_create() are also missing setting the mask.
> >
> > pcrypt_create_aead() is missing both setting the mask and inheriting the
> > f
On Tue, Jun 30, 2020 at 09:56:22AM -0400, Mikulas Patocka wrote:
> Index: linux-2.6/crypto/cryptd.c
> ===
> --- linux-2.6.orig/crypto/cryptd.c2020-06-29 16:03:07.346417000 +0200
> +++ linux-2.6/crypto/cryptd.c 2020-06-30 15:49:04.2
On Tue, Jun 30, 2020 at 01:01:16PM -0400, Mikulas Patocka wrote:
> > diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c
> > index 7240e8bbdebb..643f7f1cc91c 100644
> > --- a/crypto/pcrypt.c
> > +++ b/crypto/pcrypt.c
> > @@ -232,12 +232,15 @@ static int pcrypt_create_aead(struct crypto_template
> > *tm
From: Mikulas Patocka
Don't use crypto drivers that have the flag CRYPTO_ALG_ALLOCATES_MEMORY
set. These drivers allocate memory and thus they are unsuitable for block
I/O processing.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-crypt.c | 17 +++--
1 file changed, 11 insertions
ew template instance.
- Inherit the flags in various places that were missed.
- Other cleanups.
Note: Mikulas's patch "crypto: set the flag CRYPTO_ALG_ALLOCATES_MEMORY"
still needs to be checked for cases where the flag no longer needs to be
set due to the usage constraints I docu
From: Eric Biggers
Introduce a new algorithm flag CRYPTO_ALG_ALLOCATES_MEMORY. If this
flag is set, then the driver allocates memory in its request routine.
Such drivers are not suitable for disk encryption because GFP_ATOMIC
allocation can fail anytime (causing random I/O errors) and
From: Eric Biggers
The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a
template is instantiated, the template will have CRYPTO_ALG_ASYNC set if
any of the algorithms it uses has CRYPTO_ALG_ASYNC set.
We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that
: __virtio_crypto_skcipher_do_req
drivers/crypto/xilinx/zynqmp-aes-gcm.c: zynqmp_aes_aead_cipher
Signed-off-by: Mikulas Patocka
[EB: avoid overly-long lines]
Signed-off-by: Eric Biggers
---
.../crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 12 +-
.../crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 12 +-
drivers
From: Eric Biggers
The type and mask arguments to aead_geniv_alloc() are always 0, so
remove them.
Signed-off-by: Eric Biggers
---
crypto/echainiv.c | 2 +-
crypto/geniv.c | 7 ---
crypto/seqiv.c | 2 +-
include/crypto/internal/geniv.h | 2
From: Eric Biggers
Remove crypto_check_attr_type(), since it's no longer used.
Signed-off-by: Eric Biggers
---
crypto/algapi.c | 15 ---
include/crypto/algapi.h | 1 -
2 files changed, 16 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 24a5627
From: Eric Biggers
This series updates the crypto API to consistently prevent using keyed
algorithms without setting the key. Currently this is prevented for
AF_ALG but not for other crypto API users, which is very problematic for
other places in the kernel where userspace can specify a hash
From: Eric Biggers
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns. Add it.
Note that the new function actually has to support both shash and
From: Eric Biggers
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance. This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when p
From: Eric Biggers
Currently, almost none of the keyed hash algorithms check whether a key
has been set before proceeding. Some algorithms are okay with this and
will effectively just use a key of all 0's or some other bogus default.
However, others will severely break, as demonstrated
From: Eric Biggers
We need to consistently enforce that keyed hashes cannot be used without
setting the key. To do this we need a reliable way to determine whether
a given hash algorithm is keyed or not. AF_ALG currently does this by
checking for the presence of a ->setkey() method. Howe
From: Eric Biggers
Since Poly1305 requires a nonce per invocation, the Linux kernel
implementations of Poly1305 don't use the crypto API's keying mechanism
and instead expect the key and nonce as the first 32 bytes of the data.
But ->setkey() is still defined as a stub returning
From: Eric Biggers
Similar to what was done for the hash API, update the AEAD API to track
whether each transform has been keyed, and reject encryption/decryption
if a key is needed but one hasn't been set.
This isn't quite as important as the equivalent fix for the hash API
bec
From: Eric Biggers
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd instance. This change
is necessary for mcryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called w
From: Eric Biggers
Similar to what was done for the hash API, update the skcipher API to
track whether each transform has been keyed, and reject
encryption/decryption if a key is needed but one hasn't been set.
This isn't as important as the equivalent fix for the hash API because
From: Eric Biggers
Now that the crypto API prevents a keyed hash from being used without
setting the key, there's no need for GHASH to do this check itself.
Signed-off-by: Eric Biggers
---
crypto/ghash-generic.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/crypto/ghash-generi
On Wed, Jan 03, 2018 at 12:58:02AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 72bca2084a21edda74b802bc076083d5951f67b4
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console ou
From: Eric Biggers
Convert salsa20-generic from the deprecated "blkcipher" API to the
"skcipher" API, in the process fixing it up to be thread-safe (as the
crypto API expects) by maintaining each request's state separately from
the transform context.
Also remove the
From: Eric Biggers
Convert salsa20-asm from the deprecated "blkcipher" API to the
"skcipher" API, in the process fixing it up to use the generic helpers.
This allows removing the salsa20_keysetup() and salsa20_ivsetup()
assembly functions, which aren't performance cr
From: Eric Biggers
Export the Salsa20 constants, transform context, and initialization
functions so that they can be reused by the x86 implementation.
Signed-off-by: Eric Biggers
---
crypto/salsa20_generic.c | 20 +++-
include/crypto/salsa20.h | 27
From: Eric Biggers
This series converts the Salsa20 implementations over to the skcipher
API, in the process fixing a couple bugs and making them be more similar
to the ChaCha20 implementations, rather than doing things slightly
differently for no good reason. (Note, however, that Salsa20 still
On Sat, Dec 30, 2017 at 09:37:44AM +0100, Steffen Klassert wrote:
> On Sat, Dec 23, 2017 at 02:29:42PM -0600, Eric Biggers wrote:
> > [+Cc Steffen Klassert ]
> >
> >
> > I was able to reproduce this by trying to use 'pcrypt' recursively. I am
> > not
install"
> >> procedure. No error reported while building. But at boot the
> >> kernel immediately fails as follows, apparently while loading/parsing
> >> an X.509 certificate:
> >
> > The BUG_ON() you hit is this one in public_key_verify_signature():
On Wed, Jan 17, 2018 at 06:36:16AM +0100, Paolo Valente wrote:
>
>
> > Il giorno 17 gen 2018, alle ore 06:16, Eric Biggers
> > ha scritto:
> >
> > Hi Paolo,
> >
> > On Fri, Jan 12, 2018 at 07:06:12AM +0100, Paolo Valente wrote:
> >>
>
On Fri, Dec 22, 2017 at 11:22:38AM -0600, Eric Biggers wrote:
> [+Cc keyri...@vger.kernel.org]
>
> On Fri, Dec 22, 2017 at 07:55:01AM -0800, syzbot wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 9035a8961b504d0997369509ab8c6b1f0a4ee33d
>
On Mon, Nov 27, 2017 at 10:56:46AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 1ea8d039f9edcfefb20d8ddfe136930f6e551529
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C repro
On Fri, Dec 22, 2017 at 11:33:02PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
On Tue, Dec 19, 2017 at 11:49:02PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
On Thu, Jan 18, 2018 at 11:07:50AM +0100, Paolo Valente wrote:
>
>
> > Il giorno 17 gen 2018, alle ore 12:08, David Howells
> > ha scritto:
> >
> > If this happened during boot, it could be that you have an X.509 cert for
> > which the digest algorithm isn't built into the kernel.
> >
>
> Ye
From: Eric Biggers
The SHA-512 multibuffer code keeps track of the number of blocks pending
in each lane. The minimum of these values is used to identify the next
lane that will be completed. Unused lanes are set to a large number
(0x) so that they don't affect this calcul
From: Eric Biggers
The HASH_FIRST flag is never set. Remove it.
Signed-off-by: Eric Biggers
---
arch/x86/crypto/sha1-mb/sha1_mb.c | 28 +++-
arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 8 +++-
2 files changed, 6 insertions(+), 30 deletions(-)
diff --git a/arch
From: Eric Biggers
There is no need for ahash_mcryptd_{update,final,finup,digest}(); we
should just call crypto_ahash_*() directly.
Signed-off-by: Eric Biggers
---
crypto/mcryptd.c | 34 --
include/crypto/internal/hash.h | 5 -
2 files
From: Eric Biggers
The HASH_FIRST flag is never set. Remove it.
Signed-off-by: Eric Biggers
---
arch/x86/crypto/sha512-mb/sha512_mb.c | 30 +++---
arch/x86/crypto/sha512-mb/sha512_mb_ctx.h | 8 +++-
2 files changed, 6 insertions(+), 32 deletions(-)
diff
From: Eric Biggers
The HASH_FIRST flag is never set. Remove it.
Signed-off-by: Eric Biggers
---
arch/x86/crypto/sha256-mb/sha256_mb.c | 27 +++
arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 8 +++-
2 files changed, 6 insertions(+), 29 deletions(-)
diff --git a
On Thu, Jan 25, 2018 at 01:58:38PM -0800, Tim Chen wrote:
> On 01/24/2018 07:10 PM, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The HASH_FIRST flag is never set. Remove it.
> >
> > Signed-off-by: Eric Biggers
> > ---
> >
Hi Benjamin,
On Tue, Jan 30, 2018 at 04:08:57PM +0100, Benjamin Warnke wrote:
> Currently ZRAM uses the compression-algorithms from the crypto-api.
> None of the current compression-algorithms in the crypto-api is designed
> to compress 4KiB chunks of data efficiently.
> This patch adds a new comp
On Mon, Dec 18, 2017 at 11:36:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
On Tue, Dec 19, 2017 at 01:03:00PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
On Sun, Dec 17, 2017 at 09:51:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 41d8c16909ebda40f7b4982a7f5e2ad102705ade
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
On Sat, Dec 23, 2017 at 01:58:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry Vyukov wrote:
> On Fri, Feb 2, 2018 at 2:48 PM, syzbot
> wrote:
> > Hello,
> >
> > syzbot hit the following crash on upstream commit
> > 7109a04eae81c41ed529da9f3c48c3655ccea741 (Thu Feb 1 17:37:30 2018 +)
> > Merge git://git.kernel.org/pub/scm/
On Sat, Dec 23, 2017 at 11:54:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
From: Eric Biggers
If there is a blacklisted certificate in a SignerInfo's certificate
chain, then pkcs7_verify_sig_chain() sets sinfo->blacklisted and returns
0. But, pkcs7_verify() fails to handle this case appropriately, as it
actually continues on to the line 'actual_ret = 0;
From: Eric Biggers
The PKCS#7 parser is guaranteed to set ->sig->hash_algo for every
SignerInfo, since pkcs7_sig_note_digest_algo() is a mandatory action in
the PKCS#7 ASN.1 grammar, and it returns an error code if an
unrecognized DigestAlgorithmIdentifier is given rather than leavi
From: Eric Biggers
Hi David, here is another set of fixes and cleanups for the PKCS#7 and
X.509 code:
Patches 1-5 fix the BUG_ON() in public_key_verify_signature() reported
by Paolo Valente as well as several other bugs I found. Notably both
the PKCS#7 certificate chain verification and
From: Eric Biggers
The X.509 parser is guaranteed to set cert->sig->pkey_algo and
cert->sig->hash_algo, since x509_note_pkey_algo() is a mandatory action
in the X.509 ASN.1 grammar, and it returns an error code if an
unrecognized AlgorithmIdentifier is given rather than leaving the
a
From: Eric Biggers
The X.509 parser is guaranteed to set cert->pub->pkey_algo, since
x509_extract_key_data() is a mandatory action in the X.509 ASN.1
grammar, and it returns an error code if an unrecognized
AlgorithmIdentifier is given rather than leaving the algorithm as NULL.
The
From: Eric Biggers
The self_signed flag on a certificate implies we verified its signature.
Hence, the signature cannot have been unsupported.
Remove the dead code that resulted from this oversight.
Signed-off-by: Eric Biggers
---
crypto/asymmetric_keys/pkcs7_verify.c | 18
From: Eric Biggers
When pkcs7_verify_sig_chain() is building the certificate chain for a
SignerInfo using the certificates in the PKCS#7 message, it is passing
the wrong arguments to public_key_verify_signature(). Consequently,
when the next certificate is supposed to be used to verify the
From: Eric Biggers
If none of the certificates in a SignerInfo's certificate chain match a
trusted key, nor is the last certificate signed by a trusted key, then
pkcs7_validate_trust_one() tries to check whether the SignerInfo's
signature was made directly by a trusted key. But, i
From: Eric Biggers
The X.509 parser mishandles the case where the certificate's signature's
hash algorithm is not available in the crypto API. In this case,
x509_get_sig_params() doesn't allocate the cert->sig->digest buffer;
this part seems to be
From: Eric Biggers
The asymmetric key type allows an X.509 certificate to be added even if
its signature's hash algorithm is not available in the crypto API. In
that case 'payload.data[asym_auth]' will be NULL. But the key
restriction code failed to check for this case before tr
lerated implementation is much faster than the generic
implementation and therefore is the implementation that would primarily
be used in practice on the devices we are targeting.
There is no AArch64 implementation added, since such CPUs are likely to
have the Cryptography Extensions, allowing th
de
would be a brand new crypto construction and would be more complicated
and difficult to implement efficiently in comparison to Speck-XTS.
Signed-off-by: Eric Biggers
---
crypto/Kconfig | 14 +++
crypto/Makefile | 1 +
crypto/speck.c | 294 +
le, while the generic encryption and decryption functions are
needed as fallbacks and for the XTS tweak encryption.
Signed-off-by: Eric Biggers
---
crypto/speck.c | 90 +++---
include/crypto/speck.h | 62 ++
2 file
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
8-bit
block size.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 9 +
crypto/testmgr.h | 671 +++
2 files changed, 680 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6583c11f0f0b..4b5fce3910f8 100644
--- a/crypto/test
urse, when possible users should use Speck128-XTS, but even
that may be too slow on some processors; Speck64-XTS can be faster.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Kconfig | 6 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/speck-neon-co
On Wed, Feb 07, 2018 at 08:47:05PM -0500, Jeffrey Walton wrote:
> 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
On Sun, Dec 03, 2017 at 12:31:01PM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 4131d5166185d0d75b5f1d4bf362a9e0bac05598
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
Hi all,
On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote:
> > Hi Jeffrey,
> >
> > I see you wrote the SPECK implementation in Crypto++, and you are treating
> > the
> > words as big endian.
> >
> > Do you have a reference for this being the "correct" order? Unfortunately
> > the
>
Hi Jeff,
On Mon, Feb 12, 2018 at 02:57:06PM -0500, Jeffrey Walton wrote:
> On Mon, Feb 12, 2018 at 2:19 PM, Eric Biggers wrote:
> > Hi all,
> >
> > On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote:
> >> > Hi Jeffrey,
> >> >
> >>
orders the authors recommended in a correspondence with them. The
test vectors are taken from the original paper but were mapped to byte
arrays using the recommended byte and word orders.
Signed-off-by: Eric Biggers
---
crypto/Kconfig | 14 +++
crypto/Makefi
urse, when possible users should use Speck128-XTS, but even
that may be too slow on some processors; Speck64-XTS can be faster.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Kconfig | 6 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/speck-neon-co
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
8-bit
block size.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 9 +
crypto/testmgr.h | 671 +++
2 files changed, 680 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index e011a347d51b..9f82e7bc9c56 100644
--- a/crypto/test
use of AES.
Changed since v1:
- Use the word order recommended by the Speck authors. All test
vectors were updated.
Eric Biggers (5):
crypto: add support for the Speck block cipher
crypto: speck - export common helpers
crypto: arm/speck - add NEON-accelerated implementation of Speck-
le, while the generic encryption and decryption functions are
needed as fallbacks and for the XTS tweak encryption.
Signed-off-by: Eric Biggers
---
crypto/speck.c | 90 +++---
include/crypto/speck.h | 62 ++
2 file
Hi Ard,
On Tue, Feb 13, 2018 at 11:34:36AM +, Ard Biesheuvel wrote:
> Hi Eric,
>
> On 12 February 2018 at 23:52, Eric Biggers wrote:
> > Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
> > 128-byte chunks at a time, i.e. 8 blocks for Spec
ng the use of AES. An AArch64
implementation can be added later if there is interest though.
Changed since v2:
- Fix __speck64_xts_crypt() to work on big endian CPUs.
Changed since v1:
- Use the word order recommended by the Speck authors. All test
vectors were updated.
Eric Biggers (5):
cry
orders the authors recommended in a correspondence with them. The
test vectors are taken from the original paper but were mapped to byte
arrays using the recommended byte and word orders.
Signed-off-by: Eric Biggers
---
crypto/Kconfig | 14 +++
crypto/Makefi
le, while the generic encryption and decryption functions are
needed as fallbacks and for the XTS tweak encryption.
Signed-off-by: Eric Biggers
---
crypto/speck.c | 90 +++---
include/crypto/speck.h | 62 +
2 files cha
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
8-bit
block size.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 9 +
crypto/testmgr.h | 671 +++
2 files changed, 680 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index e011a347d51b..9f82e7bc9c56 100644
--- a/crypto/testmgr.c
urse, when possible users should use Speck128-XTS, but even
that may be too slow on some processors; Speck64-XTS can be faster.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Kconfig | 6 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/speck-neon-co
Hi David,
On Thu, Feb 15, 2018 at 03:54:26PM +, David Howells wrote:
> kmalloc() can't always allocate large enough buffers for big_key to use for
> crypto (1MB + some metadata) so we cannot use that to allocate the buffer.
> Further, vmalloc'd pages can't be passed to sg_init_one() and the ae
On Fri, Feb 09, 2018 at 10:11:06PM +, James Hogan wrote:
> +static struct shash_alg crc32_alg = {
> + .digestsize = CHKSUM_DIGEST_SIZE,
> + .setkey = chksum_setkey,
> + .init = chksum_init,
> + .update
Hi David,
On Thu, Feb 15, 2018 at 10:53:49PM +, David Howells wrote:
> /*
> + * Free up the buffer.
> + */
> +static void big_key_free_buffer(struct big_key_buf *buf)
> +{
> + unsigned int i;
> +
> + vunmap(buf->virt);
> + for (i = 0; i < buf->nr_pages; i++)
> + if (bu
g with random sglist divisions, during which I found a bug in
ecb-cast5-avx which this series fixes as well.
The overall diff is about 3100 lines of code removed, mainly due to the
ablk_helper => crypto_simd conversions and removing the unnecessary LRW
and XTS implementations.
Eric Biggers (30):
501 - 600 of 1650 matches
Mail list logo
