Re: [PATCH v2 0/5] crypto: Speck support

On Wed, Apr 25, 2018 at 8:49 PM, Eric Biggers wrote: > I agree that my explanation should have been better, and should have > considered > more crypto algorithms. The main difficulty is that we have extreme > performance > requirements -- it needs to be 50 MB/s at the very

Re: [PATCH v2 0/5] crypto: Speck support

Hi Samuel, On Wed, Apr 25, 2018 at 03:33:16PM +0100, Samuel Neves wrote: > Let's put the provenance of Speck aside for a moment, and suppose that > it is an ideal block cipher. There are still some issues with this > patch as it stands. > > - The rationale seems off. Consider this bit from the

Re: [PATCH v2 1/2] crypto: ccree: enable support for hardware keys

Hi, Gilad, On 04/23/2018 10:25 AM, Gilad Ben-Yossef wrote: Enable CryptoCell support for hardware keys. Hardware keys are regular AES keys loaded into CryptoCell internal memory via firmware, often from secure boot ROM or hardware fuses at boot time. As such, they can be used for enc/dec

RE: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

> -Original Message- > From: Eric Biggers > Sent: Tuesday, 27 March 2018 9:55 > To: Yael Chemla > Cc: Alasdair Kergon ; Mike Snitzer ; > dm-de...@redhat.com; linux-ker...@vger.kernel.org;

[PATCH 7/7] chtls: handling HW supported sockopt

some of the supported socket options are sent to HW while rest are handled by SW Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls.h | 10 ++ drivers/crypto/chelsio/chtls/chtls_cm.h | 12 ++ drivers/crypto/chelsio/chtls/chtls_hw.c | 2 +-

[PATCH 6/7] chtls: generic handling for data and header

removed redundant check and made TLS PDU and header recv handling common as received from HW Signed-off-by: Atul Gupta Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chtls/chtls.h| 10 ++ drivers/crypto/chelsio/chtls/chtls_cm.c | 12

[PATCH 5/7] chtls: free beyond end of array rspq_skb_cache

Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/chelsio/chtls/chtls_main.c

[PATCH 4/7] chtls: kbuild warnings

- unindented continue - check for null page - signed return Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

[PATCH 2/7] chtls: support only 128b key length

corrected the key length to copy 128b key. Removed 192b and 256b key as user input supports key of size 128b in gcm_ctx Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_hw.c | 6 +- 1 file changed,

[PATCH 3/7] chtls: variable dereferenced before null check

skb dereferenced before check in sendpage Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 1/7] chtls: wait for memory in Tx path

wait for memory in sendmsg and sendpage Reported-by: Gustavo A. R. Silva Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls.h | 1 + drivers/crypto/chelsio/chtls/chtls_io.c | 90 +--

Re: [PATCH v2 0/5] crypto: Speck support

Let's put the provenance of Speck aside for a moment, and suppose that it is an ideal block cipher. There are still some issues with this patch as it stands. - The rationale seems off. Consider this bit from the commit message: > Other AES alternatives such as Twofish, Threefish, Camellia,

Re: [PATCH 1/2] crypto: sm4 - export encrypt/decrypt routines to other drivers

On Wed, Apr 25, 2018 at 3:20 PM, Ard Biesheuvel wrote: > In preparation of adding support for the SIMD based arm64 implementation > of arm64, which requires a fallback to non-SIMD code when invoked in > certain contexts, expose the generic SM4 encrypt and decrypt

Re: [PATCH 1/2] crypto: sm4 - export encrypt/decrypt routines to other drivers

On 25 April 2018 at 14:20, Ard Biesheuvel wrote: > In preparation of adding support for the SIMD based arm64 implementation > of arm64, SM4 ^^^ > which requires a fallback to non-SIMD code when invoked in > certain contexts, expose the generic SM4 encrypt and decrypt

[PATCH 1/2] crypto: sm4 - export encrypt/decrypt routines to other drivers

In preparation of adding support for the SIMD based arm64 implementation of arm64, which requires a fallback to non-SIMD code when invoked in certain contexts, expose the generic SM4 encrypt and decrypt routines to other drivers. Signed-off-by: Ard Biesheuvel ---

[PATCH 2/2] crypto: arm64 - add support for SM4 encryption using special instructions

Add support for the SM4 symmetric cipher implemented using the special SM4 instructions introduced in ARM architecture revision 8.2. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/Kconfig | 6 ++ arch/arm64/crypto/Makefile | 3 +

[PATCH 0/2] crypto: implement SM4 for arm64 using special instructions

Patch #1 makes some preparatory changes so the C routines can be used as a fallback by other drivers. Patch #2 implements the SM4 core cipher using the special instructions introduced as an optional extension by revision 8.2 of the ARM architecture. Note that this does not implement