> On Dec 18, 2020, at 04:10, Eric Biggers wrote:
>
> On Wed, Dec 16, 2020 at 09:41:38AM -0800, Chang S. Bae wrote:
>> [1] Intel Architecture Instruction Set Extensions Programming Reference:
>>
>> https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instructi
> On Dec 18, 2020, at 04:10, Eric Biggers wrote:
>
> On Wed, Dec 16, 2020 at 09:41:42AM -0800, Chang S. Bae wrote:
>> When the system state switches to these sleep states, the internal key gets
>> reset. Since this system transition is transparent to userspace, the
>> internal key needs to be r
On Thu, Dec 17, 2020 at 06:15:40PM +0100, David Sterba wrote:
> On Tue, Dec 15, 2020 at 03:47:06PM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > In preparation for adding architecture-specific implementations of
> > BLAKE2b, create a header that contains common
> > constants, structs
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
Move the boilerplate code for setkey(), init(), update(), and final()
from blake2s_generic.ko into a new module blake2s_helpers.ko, and export
it so that it can be used by other shash implementations of BLAKE2s.
setkey() and init() are exported as-is, while update() and final(
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
Signed-off-by: Eric Biggers
---
crypto
This patchset adds 32-bit ARM assembly language implementations of
BLAKE2b and BLAKE2s.
The BLAKE2b implementation is NEON-accelerated, while the BLAKE2s
implementation uses scalar instructions since NEON doesn't work very
well for it. The BLAKE2b implementation is faster and is expected to be
us
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
When available, select the new implementation of BLAKE2s for 32-bit ARM.
This is faster than the generic C implementation.
Signed-off-by: Eric Biggers
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index
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.
Signed-off-by: Eric Biggers
---
crypto/blake2s_generic.c | 2 --
1
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.
Signed-off-by: Eric Biggers
---
arch/x86/crypto/blake2s-glue.c | 84 +++
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.
Signed-off-by: Eric Biggers
---
crypto/blake2s_generic.c | 88 -
From: Eric Biggers
In preparation for adding optimized implementations of BLAKE2b (as well
as possibly supporting BLAKE2b through the library API in the future),
create headers and that
contain common constants, structs, and helper functions for BLAKE2b.
Furthermore, export helper functions th
From: Eric Biggers
The shash_alg structs for the four variants of BLAKE2b are identical
except for the algorithm name, driver name, and digest size. So, avoid
code duplication by using a macro to define these structs.
Reviewed-by: David Sterba
Signed-off-by: Eric Biggers
---
crypto/blake2b_g
From: Eric Biggers
Rename some BLAKE2b-related constants to be consistent with the names
used in the BLAKE2s implementation (see include/crypto/blake2s.h):
BLAKE2B_*_DIGEST_SIZE => BLAKE2B_*_HASH_SIZE
BLAKE2B_BLOCKBYTES => BLAKE2B_BLOCK_SIZE
BLAKE2B_KEYBYTES =>
On 12/16/20 9:41 AM, Chang S. Bae wrote:
> +config CRYPTO_AES_KL
> + tristate "AES cipher algorithms (AES-KL)"
> + depends on X86_KEYLOCKER
> + select CRYPTO_AES_NI_INTEL
> + help
> + Use AES Key Locker instructions for AES algorithm.
> +
> + AES cipher algorithms (FIPS-
On Wed, Dec 16, 2020 at 9:46 AM Chang S. Bae wrote:
>
> Key Locker (KL) is Intel's new security feature that protects the AES key
> at the time of data transformation. New AES SIMD instructions -- as a
> successor of Intel's AES-NI -- are provided to encode an AES key and
> reference it for the AE
On Wed, Dec 16, 2020 at 07:24:30PM +0800, Zhou Wang wrote:
> On 2020/6/23 23:04, Bjorn Helgaas wrote:
> > On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote:
> >> Have studied _DSM method, two issues we met comparing using quirk.
> >>
> >> 1. Need change definition of either pci_host_brid
On Thu, Dec 17, 2020 at 11:11 AM Eric Biggers wrote:
>
> On Wed, Dec 16, 2020 at 09:41:38AM -0800, Chang S. Bae wrote:
> > [1] Intel Architecture Instruction Set Extensions Programming Reference:
> >
> > https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-inst
On Wed, Dec 16, 2020 at 09:41:38AM -0800, Chang S. Bae wrote:
> [1] Intel Architecture Instruction Set Extensions Programming Reference:
>
> https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-$
> [2] Intel Key Locker Specification:
>
> htt
On Wed, Dec 16, 2020 at 09:41:42AM -0800, Chang S. Bae wrote:
> When the system state switches to these sleep states, the internal key gets
> reset. Since this system transition is transparent to userspace, the
> internal key needs to be restored properly.
>
> Key Locker provides a mechanism to ba
Commit 69b6f2e817e5b ("crypto: arm64/aes-neon - limit exposed routines if
faster driver is enabled") intended to hide modes from the plain NEON
driver that are also implemented by the faster bit sliced NEON one if
both are enabled. However, the defined() CPP function does not detect
if the bit slic
Counter mode is a stream cipher chaining mode that is typically used
with inputs that are of arbitrarily length, and so a tail block which
is smaller than a full AES block is rule rather than exception.
The current ctr(aes) implementation for arm64 always makes a separate
call into the assembler r
On Thu, Dec 17, 2020 at 06:15:17PM +0100, David Sterba wrote:
> On Tue, Dec 15, 2020 at 03:47:05PM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The shash_alg structs for the four variants of BLAKE2b are identical
> > except for the algorithm name, driver name, and digest size. So, a
From: Prabhjot Khurana
The Intel Keem Bay SoC can provide hardware acceleration of Elliptic
Curve Cryptography (ECC) by means of its Offload and Crypto Subsystem
(OCS).
Add the Keem Bay OCS ECC driver which leverages such hardware
capabilities to provide hardware-acceleration of ECDH-256 and ECD
From: Prabhjot Khurana
Add Keem Bay Offload and Crypto Subsystem (OCS) Elliptic Curve
Cryptography (ECC) device tree bindings.
Signed-off-by: Prabhjot Khurana
Signed-off-by: Daniele Alessandrelli
---
.../crypto/intel,keembay-ocs-ecc.yaml | 47 +++
MAINTAINERS
From: Prabhjot Khurana
Reserve ECC curve id for NIST P-384 curve.
This is done to prepare for future support of the P-384 curve by KPP
device drivers.
Signed-off-by: Prabhjot Khurana
Signed-off-by: Daniele Alessandrelli
---
include/crypto/ecdh.h | 1 +
1 file changed, 1 insertion(+)
diff --
From: Daniele Alessandrelli
Export the following additional ECC helper functions:
- ecc_alloc_point()
- ecc_free_point()
- vli_num_bits()
- ecc_point_is_zero()
- ecc_swap_digits()
This is done to allow future KPP device drivers to re-use existing code,
thus simplifying their implementation.
Fun
From: Daniele Alessandrelli
Move ecc.h header file to 'include/crypto/internal' so that it can be
easily imported from everywhere in the kernel tree.
This change is done to allow crypto device drivers to re-use the symbols
exported by 'crypto/ecc.c', thus avoiding code duplication.
Signed-off-b
Hi,
I'm posting this patch series as RFC since there are a few open points on
which I'd like to have the opinion of the crypto maintainers and the rest of
kernel community.
The patch series adds the Intel Keem Bay OCS ECC crypto driver, which
enables hardware-accelerated ECDH on the Intel Keem Ba
From: Prabhjot Khurana
Add KPP support to the crypto engine queue manager, so that it can be
used to simplify the logic of KPP device drivers as done for other
crypto drivers.
Signed-off-by: Prabhjot Khurana
Signed-off-by: Daniele Alessandrelli
---
Documentation/crypto/crypto_engine.rst | 4
On Tue, Dec 15, 2020 at 03:47:07PM -0800, Eric Biggers wrote:
> 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 clear
On Tue, Dec 15, 2020 at 03:47:05PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> The shash_alg structs for the four variants of BLAKE2b are identical
> except for the algorithm name, driver name, and digest size. So, avoid
> code duplication by using a macro to define these structs.
>
> S
On Tue, Dec 15, 2020 at 03:47:06PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> In preparation for adding architecture-specific implementations of
> BLAKE2b, create a header that contains common
> constants, structs, and helper functions for BLAKE2b.
>
> Furthermore, export the BLAKE2b g
On Tue, Dec 15, 2020 at 03:47:04PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Rename some BLAKE2b-related constants to be consistent with the names
> used in the BLAKE2s implementation (see include/crypto/blake2s.h):
>
> BLAKE2B_*_DIGEST_SIZE => BLAKE2B_*_HASH_SIZE
> BLAKE2
From: Daniele Alessandrelli
Add dependency for CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 on HAS_IOMEM to
prevent build failures.
Fixes: 88574332451380f4 ("crypto: keembay - Add support for Keem Bay OCS
AES/SM4")
Reported-by: kernel test robot
Signed-off-by: Daniele Alessandrelli
---
drivers/crypto/keem
On Thu, Dec 17, 2020 at 4:54 AM Eric Biggers wrote:
>
> On Wed, Dec 16, 2020 at 11:32:44PM +0100, Jason A. Donenfeld wrote:
> > Hi Eric,
> >
> > On Wed, Dec 16, 2020 at 9:48 PM Eric Biggers wrote:
> > > By the way, if people are interested in having my ARM scalar
> > > implementation of
> > > BL
Hello Chang,
On Wed, 16 Dec 2020 at 18:47, Chang S. Bae wrote:
>
> Key Locker (KL) is Intel's new security feature that protects the AES key
> at the time of data transformation. New AES SIMD instructions -- as a
> successor of Intel's AES-NI -- are provided to encode an AES key and
> reference i
38 matches
Mail list logo
