Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h',
so all can use it,
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 1 -
crypto/ecc.h| 37 +
crypto/ecc_curve_defs.h | 57
1. Add 'CURVE25519' curve parameter definition to
'include/crypto/ecc_curve_defs.h';
2. Enable 'CURVE25519' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reported-by: kernel test robot
---
drivers/crypto/hisilicon/Kconfig| 1 +
drivers/crypto/hisilicon
1. Add some new 'ECDH' curve parameter definitions to
'include/crypto/ecc_curve_defs.h', and reorder ECC 'Curves IDs'
in 'include/crypto/ecdh.h';
2. Enable 'ECDH' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 4 +
1. Move elliptic curve parameter definitions out to "include/crypto";
2. Add some new elliptic curve parameters definitions, and reorder
ECC 'Curves IDs';
3. Add ECDH and CURVE25519 algorithms support for Kunpeng 930.
These patches depend on:
[v2,1/6] crypto: hisilicon/hpre - add version adapt
From: Hui Tang
HPRE of Kunpeng 930 is updated on cluster numbers and configurations
of Kunpeng 920 HPRE, so we try to update this driver to make it running
okay on both chips.
Signed-off-by: Hui Tang
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h |
Algorithm type is brought in to get hardware HPRE queue
to support different algorithms.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 10 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 12 ++--
drivers/crypto/hisilicon/hpre/hpr
The glue helper's XTS routines are no longer used, so drop them.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/glue_helper-asm-avx.S | 59
arch/x86/crypto/glue_helper-asm-avx2.S| 78 --
arch/x86/crypto/glue_helper.c | 154
arch/x86/
Camellia in CTR mode is never used by the kernel directly, and is highly
unlikely to be relied upon by dm-crypt or algif_skcipher. So let's drop
the accelerated CTR mode implementation, and instead, rely on the CTR
template and the bare cipher.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/c
Twofish in CTR mode is never used by the kernel directly, and is highly
unlikely to be relied upon by dm-crypt or algif_skcipher. So let's drop
the accelerated CTR mode implementation, and instead, rely on the CTR
template and the bare cipher.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/tw
The glue helper's CTR routines are no longer used, so drop them.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/glue_helper-asm-avx.S | 45
arch/x86/crypto/glue_helper-asm-avx2.S| 58
arch/x86/crypto/glue_helper.c | 72
ar
CAST6 in CTR mode is never used by the kernel directly*, and is highly
unlikely to be relied upon by dm-crypt or algif_skcipher. So let's drop
the accelerated CTR mode implementation, and instead, rely on the CTR
template and the bare cipher.
* it is not used at all, so we might remove the acceler
Serpent in CTR mode is never used by the kernel directly, and is highly
unlikely to be relied upon by dm-crypt or algif_skcipher. So let's drop
the accelerated CTR mode implementation, and instead, rely on the CTR
template and the bare cipher.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/se
After applying my performance fixes for AES-NI in XTS mode, the only
remaining users of the x86 glue helper module are the niche algorithms
camellia, cast6, serpent and twofish.
It is not clear from the history why all these different versions of these
algorithms in XTS and CTR modes were added in
Now that the XTS template can wrap accelerated ECB modes, it can be
used to implement Twofish in XTS mode as well, which turns out to
be at least as fast, and sometimes even faster
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/twofish-avx-x86_64-asm_64.S | 53 ---
arch/x86/crypto/two
Now that the XTS template can wrap accelerated ECB modes, it can be
used to implement Serpent in XTS mode as well, which turns out to
be at least as fast, and sometimes even faster
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/serpent-avx-x86_64-asm_64.S | 48 --
arch/x86/crypto/ser
Now that the XTS template can wrap accelerated ECB modes, it can be
used to implement CAST6 in XTS mode as well, which turns out to
be at least as fast, and sometimes even faster
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 56 ---
arch/x86/crypto/cast6_a
Now that the XTS template can wrap accelerated ECB modes, it can be
used to implement Camellia in XTS mode as well, which turns out to
be at least as fast, and sometimes even faster.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/camellia-aesni-avx-asm_64.S | 180 -
arch/x86/
On Wed, Dec 23, 2020 at 9:20 PM Maciej S. Szmigiero
wrote:
>
> On 23.12.2020 22:09, Ignat Korchagin wrote:
> (..)
> > I've been looking into this for the last couple of days because of
> > other reports [1].
> > Just finished testing a possible solution. Will submit soon.
>
> Thanks for looking in
On 23.12.2020 22:09, Ignat Korchagin wrote:
(..)
I've been looking into this for the last couple of days because of
other reports [1].
Just finished testing a possible solution. Will submit soon.
Thanks for looking into it.
By the way, on a bare metal I am actually hitting a different problem
On Wed, Dec 23, 2020 at 3:37 PM Maciej S. Szmigiero
wrote:
>
> On 14.12.2020 19:11, Maciej S. Szmigiero wrote:
> > Hi,
> >
> > I hit a reproducible BUG() when scrubbing a btrfs fs on top of
> > a dm-crypt device with no_read_workqueue and no_write_workqueue
> > flags enabled.
>
> Still happens on
On Wed, Dec 23, 2020 at 04:37:34PM +0100, Maciej S. Szmigiero wrote:
>
> It looks like to me that the skcipher API might not be safe to
> call from a softirq context, after all.
skcipher is safe to use in a softirq. The problem is only in
dm-crypt where it tries to allocate memory with GFP_NOIO.
On Wed, Dec 23, 2020 at 07:39:46PM +0100, Ard Biesheuvel wrote:
>
> This should be 'select CRYPTO_LIB_AES'
Please send a follow-up. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, 22 Dec 2020 at 13:39, Marco Chiappero wrote:
>
> This patch includes a missing dependency (CRYPTO_AES) which may
> lead to an "undefined reference to `aes_expandkey'" linking error.
>
> Fixes: 5106dfeaeabe ("crypto: qat - add AES-XTS support for QAT GEN4 devices")
> Reported-by: kernel tes
On Wed, Dec 23, 2020 at 5:03 PM Jason A. Donenfeld wrote:
>
> Hi Peter,
>
> On Wed, Dec 23, 2020 at 5:01 PM Petr Tesarik wrote:
> > I never suggested that this should serve as a supportive argument. I was
> > just trying to be honest about our motivations.
> >
> > I'm a bit sad that this discuss
Hi Peter,
On Wed, Dec 23, 2020 at 5:01 PM Petr Tesarik wrote:
> I never suggested that this should serve as a supportive argument. I was just
> trying to be honest about our motivations.
>
> I'm a bit sad that this discussion has quickly gone back to the choice of
> algorithms and how they can
On Wed, 23 Dec 2020 15:32:55 +0100
"Jason A. Donenfeld" wrote:
> On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote:
> > Upfront, let me admit that SUSE has a vested interest in a FIPS-certifiable
> > Linux kernel.
>
> Sorry, but just because you have a "vested interest", or a financial
> in
On 14.12.2020 19:11, Maciej S. Szmigiero wrote:
Hi,
I hit a reproducible BUG() when scrubbing a btrfs fs on top of
a dm-crypt device with no_read_workqueue and no_write_workqueue
flags enabled.
Still happens on the current torvalds/master.
Due to this bug it is not possible to use btrfs on to
On Wed, Dec 23, 2020 at 4:26 PM Stephan Mueller wrote:
>
> Am Mittwoch, dem 23.12.2020 um 15:32 +0100 schrieb Jason A. Donenfeld:
> >
> > I would, however, be interested in a keccak-based construction. But
> > just using the keccak permutation does not automatically make it
> > "SHA-3", so we're b
Am Mittwoch, dem 23.12.2020 um 15:32 +0100 schrieb Jason A. Donenfeld:
>
> I would, however, be interested in a keccak-based construction. But
> just using the keccak permutation does not automatically make it
> "SHA-3", so we're back at the same issue again. FIPS is simply not
> interesting for o
On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote:
> Upfront, let me admit that SUSE has a vested interest in a FIPS-certifiable
> Linux kernel.
Sorry, but just because you have a "vested interest", or a financial
interest, or because you want it does not suddenly make it a good
idea. The idea
On Wed, 23 Dec 2020 13:28:51 +0100
Torsten Duwe wrote:
>[...]
> > collaboration and disengage people. More than simply reviewing patches
> > I would expect a maintainer to give directions and drive the
> > community. Asking Jason to review Nicolai's patches was a step towards
> > that, but I beli
On Fri, 18 Dec 2020 10:25:19 -0300
Marcelo Henrique Cerri wrote:
> Hi, Ted and Jason.
>
> Any updates on that?
>
> I don't believe Torsten's concerns are simply about *applying* patches
> but more about these long periods of radio silence. That kills
Exactly. I could live with replies in the s
On Wed, 23 Dec 2020 at 09:13, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Add a NEON-accelerated implementation of BLAKE2b.
>
> On Cortex-A7 (which these days is the most common ARM processor that
> doesn't have the ARMv8 Crypto Extensions), this is over twice as fast as
> SHA-256, and slightl
On Wed, 23 Dec 2020 at 09:12, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Sync the BLAKE2b code with the BLAKE2s code as much as possible:
>
> - Move a lot of code into new headers and
> , and adjust it to be like the
> corresponding BLAKE2s code, i.e. like and
> .
>
> - Rename constan
On Wed, 23 Dec 2020 at 09:12, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Add an ARM scalar optimized implementation of BLAKE2s.
>
> NEON isn't very useful for BLAKE2s because the BLAKE2s block size is too
> small for NEON to help. Each NEON instruction would depend on the
> previous one, res
On Wed, 23 Dec 2020 at 09:12, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Address the following checkpatch warning:
>
> WARNING: Use #include instead of
>
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
> include/crypto/blake2s.h | 3 +--
> 1 file changed, 1 inserti
On Wed, 23 Dec 2020 at 09:12, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Use the full path in the include guards for the BLAKE2s headers to avoid
> ambiguity and to match the convention for most files in include/crypto/.
>
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
> in
On Wed, 23 Dec 2020 at 09:12, Eric Biggers wrote:
>
> From: Eric Biggers
>
> If no key was provided, then don't waste time initializing the block
> buffer, as its initial contents won't be used.
>
> Also, make crypto_blake2s_init() and blake2s() call a single internal
> function __blake2s_init()
On Wed, 23 Dec 2020 at 09:12, Eric Biggers wrote:
>
> From: Eric Biggers
>
> The first three fields of 'struct blake2s_state' are used in assembly
> code, which isn't immediately obvious, so add a comment to this effect.
>
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
> includ
On Wed, 23 Dec 2020 at 09:12, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Add helper functions for shash implementations of BLAKE2s to
> include/crypto/internal/blake2s.h, taking advantage of
> __blake2s_update() and __blake2s_final() that were added by the previous
> patch to share more code
On Wed, 23 Dec 2020 at 09:12, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Move most of blake2s_update() and blake2s_final() into new inline
> functions __blake2s_update() and __blake2s_final() in
> include/crypto/internal/blake2s.h so that this logic can be shared by
> the shash helper functio
On Mon, Dec 14, 2020 at 12:39:29PM -0800, Eric Biggers wrote:
>
> That doesn't make sense, given that most algorithms don't implement it...
It doesn't matter for chacha, but it's still true for the Crypto
API in general.
Yes I know that lots of algorithms get it wrong, but it is on my
list of thi
From: Eric Biggers
Add a NEON-accelerated implementation of BLAKE2b.
On Cortex-A7 (which these days is the most common ARM processor that
doesn't have the ARMv8 Crypto Extensions), this is over twice as fast as
SHA-256, and slightly faster than SHA-1. It is also almost three times
as fast as th
From: Eric Biggers
Add helper functions for shash implementations of BLAKE2s to
include/crypto/internal/blake2s.h, taking advantage of
__blake2s_update() and __blake2s_final() that were added by the previous
patch to share more code between the library and shash implementations.
crypto_blake2s_s
From: Eric Biggers
Add an ARM scalar optimized implementation of BLAKE2s.
NEON isn't very useful for BLAKE2s because the BLAKE2s block size is too
small for NEON to help. Each NEON instruction would depend on the
previous one, resulting in poor performance.
With scalar instructions, on the oth
From: Eric Biggers
The file comment for blake2b_generic.c makes it sound like it's the
reference implementation of BLAKE2b with only minor changes. But it's
actually been changed a lot. Update the comment to make this clearer.
Reviewed-by: David Sterba
Acked-by: Ard Biesheuvel
Signed-off-by:
From: Eric Biggers
Sync the BLAKE2b code with the BLAKE2s code as much as possible:
- Move a lot of code into new headers and
, and adjust it to be like the
corresponding BLAKE2s code, i.e. like and
.
- Rename constants, e.g. BLAKE2B_*_DIGEST_SIZE => BLAKE2B_*_HASH_SIZE.
- Use a macro
From: Eric Biggers
Address the following checkpatch warning:
WARNING: Use #include instead of
Signed-off-by: Eric Biggers
---
include/crypto/blake2s.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/crypto/blake2s.h b/include/crypto/blake2s.h
index 3f06
From: Eric Biggers
The first three fields of 'struct blake2s_state' are used in assembly
code, which isn't immediately obvious, so add a comment to this effect.
Signed-off-by: Eric Biggers
---
include/crypto/blake2s.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/crypto/blake2s.h
From: Eric Biggers
When available, select the new implementation of BLAKE2s for 32-bit ARM.
This is faster than the generic C implementation.
Reviewed-by: Jason A. Donenfeld
Acked-by: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
di
From: Eric Biggers
If no key was provided, then don't waste time initializing the block
buffer, as its initial contents won't be used.
Also, make crypto_blake2s_init() and blake2s() call a single internal
function __blake2s_init() which treats the key as optional, rather than
conditionally calli
From: Eric Biggers
Use the full path in the include guards for the BLAKE2s headers to avoid
ambiguity and to match the convention for most files in include/crypto/.
Signed-off-by: Eric Biggers
---
include/crypto/blake2s.h | 6 +++---
include/crypto/internal/blake2s.h | 6 +++---
2 fil
From: Eric Biggers
Move most of blake2s_update() and blake2s_final() into new inline
functions __blake2s_update() and __blake2s_final() in
include/crypto/internal/blake2s.h so that this logic can be shared by
the shash helper functions. This will avoid duplicating this logic
between the library
From: Eric Biggers
The shash_alg structs for the four variants of BLAKE2s are identical
except for the algorithm name, driver name, and digest size. So, avoid
code duplication by using a macro to define these structs.
Acked-by: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
crypto/blake2s_ge
From: Eric Biggers
It doesn't make sense for the generic implementation of BLAKE2s to
include and , as these are
things that would only be useful in an architecture-specific
implementation. Remove these unnecessary includes.
Acked-by: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
crypto/bl
From: Eric Biggers
The shash_alg structs for the four variants of BLAKE2s are identical
except for the algorithm name, driver name, and digest size. So, avoid
code duplication by using a macro to define these structs.
Acked-by: Ard Biesheuvel
Signed-off-by: Eric Biggers
---
arch/x86/crypto/b
This patchset adds 32-bit ARM assembly language implementations of
BLAKE2b and BLAKE2s.
As a prerequisite to adding these without copy-and-pasting lots of code,
this patchset also reworks the existing BLAKE2b and BLAKE2s code to
provide helper functions that make implementing "shash" providers for
57 matches
Mail list logo
