[PATCH] crypto: atmel - switch to SPDX license identifiers

Adopt the SPDX license identifiers to ease license compliance management. Signed-off-by: Tudor Ambarus --- drivers/crypto/atmel-aes.c | 5 + drivers/crypto/atmel-authenc.h | 13 + drivers/crypto/atmel-ecc.c | 11 +-- drivers/crypto/atmel-ecc.h | 14

Re: [PATCH 9/9 v2] crypto: atmel-ecc: Break out lock check helper

On 06/28/2018 04:07 PM, Linus Walleij wrote: > This breaks out a lock status checker to be used with further > refactorings. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Rebased > --- > drivers/crypto/atmel-ecc.c | 38 ++ > 1 file

Re: [PATCH 7/9 v2] crypto: atmel-ecc: Print out serial number

Hi, Linus, On 06/28/2018 04:07 PM, Linus Walleij wrote: > This reads out the serial number of the crypto chip and prints it, > also toss this into the entropy pool as it is device-unique data. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - kfree(cmd) was missed. Fix it with a

Re: [PATCH 6/9 v2] crypto: atmel-ecc: Marshal the command while sending

Hi, Linus, On 06/28/2018 04:07 PM, Linus Walleij wrote: > Instead of casting the struct for the command into (u8 *) > which is problematic in many ways, and instead of > calculating the CRC sum in a separate function, marshal, > checksum and send the command in one single function. > > Instead

Re: [PATCH 3/9 v2] crypto: atmel-ecc: More helpful error messages

Hi, Linus, On 06/28/2018 04:07 PM, Linus Walleij wrote: > Report errors once when they happen on the I2C bus so we > get good information in cases such as when the wrong I2C > address is used. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Strip some comments that are now

Re: [PATCH 2/9 v2] crypto: atmel-ecc: Just warn on missing clock frequency

Hi, Linus, On 06/28/2018 04:07 PM, Linus Walleij wrote: > The Atmel ECC driver contains a check for the I2C bus clock > frequency, so as to check that the I2C adapter in use > satisfies the device specs. > > If the device is connected to a device tree node that does not > contain a clock

[PATCH] crypto: atmel-ecc - fix to allow multi segment scatterlists

Remove the limitation of single element scatterlists. ECDH with multi-element scatterlists is needed by TPM. Similar to 'commit 95ec01ba1ef0 ("crypto: ecdh - fix to allow multi segment scatterlists")'. Signed-off-by: Tudor Ambarus --- drivers/crypto/atmel-

[PATCH] crypto: atmel-ecc - remove overly verbose dev_info

Remove it because when using a slow console, it can affect the speed of crypto operations. Similar to 'commit 730f23b66095 ("crypto: vmx - Remove overly verbose printk from AES XTS init")'. Signed-off-by: Tudor Ambarus --- drivers/crypto/atmel-ecc.c | 4 1 file changed, 4

Re: [PATCH 8/9] crypto: atmel-ecc: Detail what is unlocked

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: Instead of just providing a broad error message about the chip being unlocked provide details on what is unlocked, one line per thing that can be locked: data and OTP and configuration are locked independently. Loose the Failure to lock

Re: [PATCH 7/9] crypto: atmel-ecc: Print out serial number

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: This reads out the serial number of the crypto chip and prints it, also toss this into the entropy pool as it is device-unique data. Signed-off-by: Linus Walleij --- drivers/crypto/atmel-ecc.c | 56

Re: [PATCH 4/9] crypto: atmel-ecc: Provide config zone defines

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: The config zone has 0x16 words of 4 bytes each, so provide some basic defines so that we can address these individually. Are you going to use all these defines? I would add just the defines that are needed, when they are needed, but I

Re: [PATCH 3/9] crypto: atmel-ecc: More helpful error messages

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: Report errors once when they happen on the I2C bus so we get good information in cases such as when the wrong I2C address is used. Signed-off-by: Linus Walleij --- drivers/crypto/atmel-ecc.c | 27 +-- 1 file

Re: [PATCH 1/9] crypto: atmel-ecc: Make available for other platforms

On 06/05/2018 04:49 PM, Linus Walleij wrote: This is a pure I2C driver, and this device appears on the 96boards Secure96 mezzanine card, so we want to enable the driver on other devices. Cut the Kconfig limitations to Atmel SoC only. Signed-off-by: Linus Walleij Reviewed-by: Tudor Ambarus

Re: [PATCH 6/9] crypto: atmel-ecc: Marshal the command while sending

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: Instead of casting the struct for the command into (u8 *) which is problematic in many ways, and instead of calculating the CRC sum in a separate function, marshal, checksum and send the command in one single function. Instead of

Re: [PATCH 2/9] crypto: atmel-ecc: Silently ignore missing clock frequency

Hi, Linus, Wolfram, On 06/05/2018 04:49 PM, Linus Walleij wrote: The Atmel ECC driver contains a check for the I2C bus clock frequency, so as to check that the I2C adapter in use satisfies the device specs. If the device is connected to a device tree node that does not contain a clock

Re: [RFC PATCH 5/5] KEYS: add KPP ecdh parser

Hi, Denis, On 05/14/2018 10:54 PM, Denis Kenzior wrote: Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: The ECDH private keys are expected to be encoded with the ecdh helpers from kernel. Use the ecdh helpers to check if the key is valid. If valid, allocate a tfm and set the private

Re: [RFC PATCH 1/5] KEYS: Provide key type operations for kpp ops

Hi, Denis, Thanks for the review! Please see inline. On 05/14/2018 09:48 PM, Denis Kenzior wrote: Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: Provide three new operations in the key_type struct that can be used to provide access to kpp operations. These will be implemented

Re: [RFC PATCH 0/5] KEYS: add kpp keyctl operations

ping again. On 04/11/2018 02:08 PM, Tudor Ambarus wrote: Hi, There was a long discussion about which interface to chose to export akcipher and kpp to user-space. This series came as an alternative to what Stephan proposed for af_alg[1]. I would like some feedback before diving into tpm. Best

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: [PATCH RESEND] crypto: caam - strip input zeros from RSA input buffer

eq->src, lzeros); This is interesting, you are overwriting the request's src sg. I kept wondering if one could have a problem if we are modifying its src sg. I couldn't find any failing scenario, so: Reviewed-by: Tudor Ambarus <tudor.amba...@microchip.com>

Re: [RFC PATCH 0/5] KEYS: add kpp keyctl operations

@vger.kernel.org/msg27255.html On 02/28/2018 06:52 PM, Tudor Ambarus wrote: This series provides keyctl access for kpp operations, including a query function, a function to generate the public key that is associated with the private key and a function to compute the shared secret. I've added a KPP ecdh

[PATCH v3 2/2] crypto: authencesn - don't leak pointers to authenc keys

In crypto_authenc_esn_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/authencesn

[PATCH v3 1/2] crypto: authenc - don't leak pointers to authenc keys

In crypto_authenc_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/authenc.c |

Re: [PATCH] crypto: rsa - remove unneeded initializations

On 03/30/2018 08:27 PM, Herbert Xu wrote: On Mon, Mar 26, 2018 at 02:59:06PM +0300, Tudor Ambarus wrote: Remove useless assignment of ret to -ENOMEM in rsa_verify. Remove useless initialization of ret to zero at declaration in rsa_enc/dec/sign/verify. Benefit of the power of undefined values

Re: in-kernel user of ecdsa

On 03/12/2018 07:07 PM, Tudor Ambarus wrote: Would you consider using ECDSA in the kernel module signing facility? Any feedback is good. I can invest some time to make this happen, if needed. When compared with RSA, ECDSA has shorter keys, the key generation process is faster, the sign

[PATCH] crypto: rsa - remove unneeded initializations

ed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/rsa.c | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/crypto/rsa.c b/crypto/rsa.c index b067f3a..e75ce09 100644 --- a/crypto/rsa.c +++ b/crypto/rsa.c @@ -88,7 +88,7 @@ static int rs

[PATCH v2 8/9] crypto: qat - don't leak pointers to authenc keys

In qat_alg_aead_init_sessions we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/cryp

[PATCH v2 9/9] crypto: talitos - don't leak pointers to authenc keys

In talitos's aead_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> Reviewed-by: Christophe

[PATCH v2 3/9] crypto: caam - don't leak pointers to authenc keys

In caam's aead_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/caam/caa

[PATCH v2 4/9] crypto: caam/qi - don't leak pointers to authenc keys

In caam/qi's aead_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypt

[PATCH v2 7/9] crypto: picoxcell - don't leak pointers to authenc keys

In spacc_aead_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> Reviewed-by: Jamie Il

[PATCH v2 5/9] crypto: chcr - don't leak pointers to authenc keys

In chcr_authenc_setkey and chcr_aead_digest_null_setkey we save pointers to the authenc keys in local variables of type struct crypto_authenc_keys and we don't zeroize them after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.

[PATCH v2 6/9] crypto: ixp4xx - don't leak pointers to authenc keys

In ixp4xx's aead_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/

[PATCH v2 1/9] crypto: authenc - don't leak pointers to authenc keys

In crypto_authenc_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/authenc.

[PATCH v2 2/9] crypto: authencesn - don't leak pointers to authenc keys

In crypto_authenc_esn_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/authen

[PATCH v2 0/9] crypto: don't leak pointers to authenc keys

and Christophe's Reviewed-by tag Tudor Ambarus (9): crypto: authenc - don't leak pointers to authenc keys crypto: authencesn - don't leak pointers to authenc keys crypto: caam - don't leak pointers to authenc keys crypto: caam/qi - don't leak pointers to authenc keys crypto: chcr - don't

[PATCH 6/9] crypto: ixp4xx - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/ixp4xx_crypto.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c index 717a266..27f7dad 100644 --- a/drivers/crypto/ixp4xx_crypto.c +++ b/d

[PATCH 7/9] crypto: picoxcell - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/picoxcell_crypto.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c index 4ef52c9..a4df966 100644 --- a/drivers/crypto/picoxcell_crypto.c

[PATCH 2/9] crypto: authencesn - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/authencesn.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/crypto/authencesn.c b/crypto/authencesn.c index 15f91dd..3bed6d1 100644 --- a/crypto/authencesn.c +++ b/crypto/authencesn.c @@

[PATCH 9/9] crypto: talitos - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/talitos.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 447cb8b..c92efc7 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -

[PATCH 8/9] crypto: qat - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/qat/qat_common/qat_algs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c index baffae8..1138e41 100644 --- a/drivers/

[PATCH 0/9] don't leak pointers to authenc keys

There are few places in crypto where we save pointers to the authenc keys to a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix all those cases and don't leak pointers to the authenc keys. Tudor Ambarus (9): crypto: authenc - don't leak pointers

[PATCH 4/9] crypto: caam/qi - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/caam/caamalg_qi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/caam/caamalg_qi.c b/drivers/crypto/caam/caamalg_qi.c index c2b5762..cacda08 100644 --- a/drivers/crypto/caam/caamalg_qi.c

[PATCH 5/9] crypto: chcr - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/chelsio/chcr_algo.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c index 4617c7a..91bc77a 100644 --- a/drivers/crypto/c

[PATCH 3/9] crypto: caam - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/caam/caamalg.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c index 584a6c1..7207a53 100644 --- a/drivers/crypto/caam/caamalg.c +++ b/drivers/

[PATCH 1/9] crypto: authenc - don't leak pointers to authenc keys

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/authenc.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/crypto/authenc.c b/crypto/authenc.c index d3d6d72..480a08b 100644 --- a/crypto/authenc.c +++ b/crypto/authenc.c @@ -87,8 +87,10 @@

Re: [PATCH] crypto: atmel-aes - fix the keys zeroing on errors

Hi, Antoine, On 02/23/2018 02:37 PM, Antoine Tenart wrote: Hi Tudor, On Fri, Feb 23, 2018 at 02:04:33PM +0200, Tudor Ambarus wrote: There are few other places in crypto where we extract the authenc keys in the same type of local variable, struct crypto_authenc_keys keys, and we don't zeroize

in-kernel user of ecdsa

Hi, Would you consider using ECDSA in the kernel module signing facility? When compared with RSA, ECDSA has shorter keys, the key generation process is faster, the sign operation is faster, but the verify operation is slower than with RSA. Smaller key sizes imply reduced memory footprint and

Re: [PATCH v2] crypto/ecc: Remove stack VLA usage

l.org/lkml/2018/3/7/621 Signed-off-by: Kees Cook<keesc...@chromium.org> Reviewed-by: Tudor Ambarus <tudor.amba...@microchip.com>

Re: [PATCH] crypto/ecc: Remove stack VLA usage

On 03/08/2018 11:55 PM, Kees Cook wrote: Looks like there are few intermediate buffers in ecc that should be zeroized as well. Can you send a patch for those? Yeah, I'll take a look. Best, ta

Re: [PATCH] crypto/ecc: Remove stack VLA usage

Hi, Kees, On 03/07/2018 11:56 PM, Kees Cook wrote: On the quest to remove all VLAs from the kernel[1], this switches to a pair of kmalloc regions instead of using the stack. This also moves the get_random_bytes() after all allocations (and drops the needless "nbytes" variable). [1]

[RFC PATCH 5/5] KEYS: add KPP ecdh parser

times as needed. ECDH keys can be loaded like this: # echo -n 020028000200200024d121ebe5cf2d83f6621b6e43843aa38be086c32019da92505303e1c0eab882 \ | xxd -r -p | keyctl padd asymmetric private @s Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/asymmetri

[RFC PATCH 3/5] KEYS: Provide missing asym kpp subops for new key type ops

Includes kpp_query, kpp_gen_pubkey and kpp_compute_ss. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/asymmetric_keys/asymmetric_type.c | 77 include/keys/asymmetric-subtype.h| 12 + 2 files changed, 89 insertions(+) diff

[RFC PATCH 4/5] KEYS: add asymmetric kpp subtype

ccb4da74b1473fea6c709e382dc7aab729b2470319abdd34bda82c93e1a474d96463f770202fa4e69f4a38ccc02c492fb132bbaf2261dacb6fdba9aafc7781f3 | xxd -r -p > /tmp/bpub # keyctl kpp_compute_ss 266205365 0 /tmp/bpub | xxd -p ea176f7e6e5726388bfb41ebbac86da5a872d1ffc9473daa58439f340f8c f3c9 Signed-off-by: Tudor Amba

[RFC PATCH 2/5] KEYS: Provide keyctls to drive the new key type ops for kpp

the amount of data written into the output buffer. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- Documentation/security/keys/core.rst | 59 ++ include/uapi/linux/keyctl.h | 16 +++ security/keys/Makefile | 1 + security/keys/co

[RFC PATCH 1/5] KEYS: Provide key type operations for kpp ops

, const void *in, void *out); Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- Documentation/security/keys/core.rst | 54 include/linux/key-type.h | 7 + include/linux/keyctl.h | 11 include/uapi/linux/ke

[RFC PATCH 0/5] KEYS: add kpp keyctl operations

, please let me know how you feel about this series. Tudor Ambarus (5): KEYS: Provide key type operations for kpp ops KEYS: Provide keyctls to drive the new key type ops for kpp KEYS: Provide missing asym kpp subops for new key type ops KEYS: add asymmetric kpp subtype KEYS: add KPP ecdh parser

Re: [PATCH] crypto: atmel-aes - fix the keys zeroing on errors

pport to authenc(hmac(shaX), Y(aes)) modes") Signed-off-by: Antoine Tenart<antoine.ten...@bootlin.com> Reviewed-by: Tudor Ambarus <tudor.amba...@microchip.com> There are few other places in crypto where we extract the authenc keys in the same type of local variable, struct crypto_aut

Re: [PATCH] Remove useless assignment in rsa_verify

Hi, Ben, On 02/22/2018 07:16 PM, C0deAi wrote: Hi my name is Benjamin Bales. I am the founder and creator of CodeAI, the first non-human contributor to your software project. CodeAI finds and fixes security defects for you. It fixed 327. It wants to merge a fix for a useless assignment. To

Re: [PATCH] crypto: atmel: Delete error messages for a failed memory allocation in six functions

Markus Elfring<elfr...@users.sourceforge.net> Reviewed-by: Tudor Ambarus <tudor.amba...@microchip.com>

[PATCH] crypto: tcrypt - set assoc in sg_init_aead()

Results better code readability. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- Should be applied after: crypto: tcrypt - fix S/G table for test_aead_speed() crypto/tcrypt.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/crypto/tc

Re: [PATCH 1/2] crypto: tcrypt - fix S/G table for test_aead_speed()

Hi, On 11/12/2017 06:26 PM, Horia Geantă wrote: -sg[0] - (1 entry) reserved for associated data, filled outside sg_init_aead() Let's fill the sg[0] with aad inside sg_init_aead()! Cheers, ta

Re: [PATCH 1/2] crypto: tcrypt - fix S/G table for test_aead_speed()

Hi, On 10/10/2017 01:21 PM, Robert Baronescu wrote: In case buffer length is a multiple of PAGE_SIZE, the S/G table is incorrectly generated. Fix this by handling buflen = k * PAGE_SIZE separately. Signed-off-by: Robert Baronescu --- crypto/tcrypt.c | 6 -- 1

Re: [PATCH v2 5/5] crypto: dh - Remove pointless checks for NULL 'p' and 'g'

odules. Reviewed-by: Tudor Ambarus <tudor.amba...@microchip.com> Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/dh.c | 3 --- drivers/crypto/qat/qat_common/qat_asym_algs.c | 3 --- 2 files changed, 6 deletions(-) diff --git a/crypto/

Re: [PATCH v2 3/5] crypto: dh - Don't permit 'key' or 'g' size longer than 'p'

ly allowed users to cause a buffer underflow via KEYCTL_DH_COMPUTE. Fix this by updating crypto_dh_decode_key() to verify this precondition for all DH implementations. Fixes: c9839143ebbf ("crypto: qat - Add DH support") Cc: <sta...@vger.kernel.org> # v4.8+ Reviewed-by: Tudor Amba

Re: [PATCH v2 1/5] crypto: dh - Fix double free of ctx->p

/0x2c0 entry_SYSCALL_64_fastpath+0x1f/0xbe Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation") Cc: <sta...@vger.kernel.org> # v4.8+ Signed-off-by: Eric Biggers <ebigg...@google.com> Reviewed-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/dh.c | 33 +++

Re: [PATCH 2/4] crypto: dh - don't permit 'p' to be 0

:140 [inline] RSP: 88006c7cfb08 RIP: sg_init_one+0x1b3/0x240 lib/scatterlist.c:156 RSP: 88006c7cfb08 Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation") Cc: <sta...@vger.kernel.org> # v4.8+ Signed-off-by: Eric Biggers <ebigg...@google.com> Revi

[v3 PATCH 2/3] crypto: atmel-aes/tdes - remove empty functions

Pointer members of an object with static storage duration, if not explicitly initialized, will be initialized to a NULL pointer. The crypto API checks if these pointers are not NULL before using them, therefore we can safely remove these empty functions. Signed-off-by: Tudor Ambarus <tudor.a

[PATCH] crypto: ecdh - remove empty exit()

Pointer members of an object with static storage duration, if not explicitly initialized, will be initialized to a NULL pointer. The crypto API checks if this pointer is not NULL before using it, we are safe to remove the function. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.

Re: [PATCH] crypto: ccm - preserve the IV buffer

uest_set_callback(skreq, pctx->flags, crypto_ccm_decrypt_done, req); Reviewed-by: Tudor Ambarus <tudor.amba...@microchip.com>

Re: [PATCH 2/4] crypto: dh - don't permit 'p' to be 0

Hi, Eric, On 11/02/2017 12:25 AM, Eric Biggers wrote: If 'p' is 0 for the software Diffie-Hellman implementation, then dh_max_size() returns 0. dh_set_secret() returns -EINVAL if p_len < 1536, see dh_check_params_length(). What am I missing? Cheers, ta

Re: [PATCH 1/4] crypto: dh - fix double free of ctx->p

Hi, Eric, On 11/02/2017 12:25 AM, Eric Biggers wrote: When setting the secret with the software Diffie-Hellman implementation, if allocating 'g' failed (e.g. if it was longer than MAX_EXTERN_MPI_BITS), then 'p' was freed twice: once immediately, and once later when the crypto_kpp tfm was

[v2 PATCH 2/3] crypto: atmel-aes/tdes - remove empty functions

this empty functions along with all the references to them. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- changes in v2: - remove empty atmel_aes_gcm_exit() drivers/crypto/atmel-aes.c | 20 drivers/crypto/atmel-tdes.c | 18 -- 2 files c

Re: Kernel panic when using ccm(aes) with the Atmel AES HW accelerator

Hi, Romain, On 10/18/2017 04:32 PM, Romain Izard wrote: diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c index 29e20c37f3a6..f3eabe1f1490 100644 --- a/drivers/crypto/atmel-aes.c +++ b/drivers/crypto/atmel-aes.c @@ -80,6 +80,7 @@ #define AES_FLAGS_BUSY BIT(3)

Re: Kernel panic when using ccm(aes) with the Atmel AES HW accelerator

Hi, Romain, On 10/18/2017 04:32 PM, Romain Izard wrote: diff --git a/crypto/ccm.c b/crypto/ccm.c index 1ce37ae0ce56..e7c2121a3ab2 100644 --- a/crypto/ccm.c +++ b/crypto/ccm.c @@ -47,6 +47,7 @@ struct crypto_ccm_req_priv_ctx { u8 odata[16]; u8 idata[16]; u8

[PATCH 3/3] crypto: atmel-aes/tdes/sha - remove useless irq init

irq would be set to -1 and then unused, if we failed to get IORESOURCE_MEM. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/atmel-aes.c | 2 -- drivers/crypto/atmel-sha.c | 2 -- drivers/crypto/atmel-tdes.c | 2 -- 3 files changed, 6 deletions(-) diff

[PATCH 1/3] crypto: atmel-aes/tdes/sha - return appropriate error code

Return -ENODEV when dma_request_slave_channel_compat() fails. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/atmel-aes.c | 3 +-- drivers/crypto/atmel-sha.c | 3 +-- drivers/crypto/atmel-tdes.c | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) diff

[PATCH 2/3] crypto: atmel-aes/tdes - remove empty function

this empty function along with all the references to it. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- drivers/crypto/atmel-aes.c | 14 -- drivers/crypto/atmel-tdes.c | 18 -- 2 files changed, 32 deletions(-) diff --git a/drivers/crypto/atmel-a

Re: Kernel panic when using ccm(aes) with the Atmel AES HW accelerator

Hi, Romain, On 10/18/2017 04:32 PM, Romain Izard wrote: my fix also led to a systematic oops when running the ccm(aes) test case. The NULL deference appears because of a memory corruption issue. atmel-aes does not implement ccm(aes), so the algorithm will be in the following form:

Re: [PATCH 1/3] crypto: dh_helper - return unsigned int for dh_data_size()

Hi, David, On 10/03/2017 12:06 PM, David Howells wrote: Tudor Ambarus <tudor.amba...@microchip.com> wrote: -static inline int dh_data_size(const struct dh *p) +static inline unsigned int dh_data_size(const struct dh *p) { return p->key_size + p->p_size

[PATCH 2/3] crypto: dh_helper - return unsigned value for crypto_dh_key_len()

DH_KPP_SECRET_MIN_SIZE and dh_data_size() are both returning unsigned values. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/dh_helper.c | 2 +- include/crypto/dh.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/crypto/dh_helper.c b/

[PATCH 3/3] KEYS: dh - make some length variables unsigned

Both crypto_kpp_maxsize() and crypto_dh_key_len() are returning unsigned integers. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- security/keys/dh.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/security/keys/dh.c b/security/keys/dh.c index d

[PATCH] crypto: ecdh_helper - return unsigned value for crypto_ecdh_key_len()

ECDH_KPP_SECRET_MIN_SIZE and params->key_size are both returning unsigned values. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- crypto/ecdh_helper.c | 2 +- include/crypto/ecdh.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/crypto/ecdh_h

Re: [v2 PATCH 5/5] Bluetooth: let the crypto subsystem generate the ecc privkey

. This backup logic should be done in crypto, if really needed. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- net/bluetooth/ecdh_helper.c | 186 net/bluetooth/ecdh_helper.h | 9 ++- net/bluetooth/selftest.c| 14 +++- net/bluetooth

[v2 PATCH 5/5] Bluetooth: let the crypto subsystem generate the ecc privkey

-by: Tudor Ambarus <tudor.amba...@microchip.com> --- net/bluetooth/ecdh_helper.c | 186 net/bluetooth/ecdh_helper.h | 9 ++- net/bluetooth/selftest.c| 14 +++- net/bluetooth/smp.c | 66 +++- 4 files changed, 147 insertions(+

[v2 PATCH 3/5] Bluetooth: selftest - check for errors when computing ZZ

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- net/bluetooth/selftest.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/selftest.c b/net/bluetooth/selftest.c index 126bdc5..ce99648 100644 --- a/net/bluetooth/selftest.c +++

[v2 PATCH 4/5] Bluetooth: ecdh_helper - fix leak of private key

tmp buffer contains the swapped private key. In case the setkey call failed, the tmp buffer was freed without clearing the private key. Zeroize the temporary buffer so we don't leak the private key. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- net/bluetooth/ecdh_helper

[v2 PATCH 2/5] Bluetooth: ecdh_helper - reveal error codes

Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- net/bluetooth/ecdh_helper.c | 32 +++- net/bluetooth/ecdh_helper.h | 8 net/bluetooth/smp.c | 17 ++--- 3 files changed, 33 insertions(+), 24 deletions(-) diff --git

[v2 PATCH 1/5] Bluetooth: move ecdh allocation outside of ecdh_helper

Before this change, a new crypto tfm was allocated, each time, for both key generation and shared secret computation. Allocate a single tfm for both cases. Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> --- net/bluetooth/ecdh_helper.c | 32 - net/blu

[v2 PATCH 0/5] Bluetooth: let the crypto subsystem generate the ecc privkey

-archive.com/linux-crypto@vger.kernel.org/msg28036.html Changes in v2: - add patches 2, 3, 4. - adress Marcel's suggestions: - revive the check for accidentally generated debug keys - bypass the handling of private key to the crypto subsytem, even when using debug keys. Tudor Ambarus (5

Re: [RESEND RFC PATCH 2/2] Bluetooth: let the crypto subsystem generate the ecc privkey

Hi, Marcel, Agreed on all suggestions, I will send a v2 patch set. Thanks, ta

Re: [RESEND RFC PATCH 1/2] Bluetooth: move ecdh allocation outside of ecdh_helper

Hi, Marcel, On 09/25/2017 04:02 PM, Marcel Holtmann wrote: diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c index a0ef897..6532689 100644 --- a/net/bluetooth/smp.c +++ b/net/bluetooth/smp.c [cut] @@ -2677,7 +2695,16 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct

[RESEND RFC PATCH 2/2] Bluetooth: let the crypto subsystem generate the ecc privkey

-by: Tudor Ambarus <tudor.amba...@microchip.com> --- net/bluetooth/ecdh_helper.c | 102 +--- net/bluetooth/smp.c | 55 +--- 2 files changed, 67 insertions(+), 90 deletions(-) diff --git a/net/bluetooth/ecdh_helper.c b/net/blu

[RESEND RFC PATCH 0/2] Bluetooth: let the crypto subsystem generate the ecc privkey

to generate and handle the ecdh private key, potentially benefiting of hardware ecc private key generation and retention. Tested with selftest and with btmon and smp-tester on top of hci_vhci, with ecdh done in both software and hardware (through atmel-ecc driver). All tests passed. Tudor Ambarus

[RFC PATCH 0/2] let the crypto subsystem generate the ecc privkey

to generate and handle the ecdh private key, potentially benefiting of hardware ecc private key generation and retention. Tested with selftest and with btmon and smp-tester on top of hci_vhci, with ecdh done in both software and hardware (through atmel-ecc driver). All tests passed. Tudor Ambarus (2

Re: KPP questions and confusion

Hi, Marcel, On 08/03/2017 11:40 AM, Marcel Holtmann wrote: Essentially we do what all other key exchange procedure do. Generate a private/public key pair, give the public key to the other side, run DH with the value from the other side. That Bluetooth SMP knows about the private key is

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi, Marcel, On 08/30/2017 10:21 AM, Marcel Holtmann wrote: you still need to get the public key out of the kernel if you want to use it from user space. Or feed the remote public key if you plan to use some sort of key derivation function. The crypto hardware that I'm working on, generates

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

, Tudor Ambarus wrote: Hi, all, On 08/11/2017 07:05 PM, Marcel Holtmann wrote: Hi Stephan, AF_ALG is best suited for crypto use cases where a socket is set up once and there are lots of reads and writes to justify the setup cost. With asymmetric crypto, the setup cost is high when you might

Re: [PATCH 7/8] crypto: ecdh - constify key

crypto/ecdh.h +++ b/include/crypto/ecdh.h @@ -40,7 +40,7 @@ */ struct ecdh { unsigned short curve_id; - char *key; + const char *key; unsigned short key_size; }; I just came across this and remembered that Stephan already made a patch, so: Acked-by: Tudor A

Re: [PATCH 0/6] Add support for ECDSA algorithm

Hi, Sandy, On 08/22/2017 08:22 PM, Sandy Harris wrote: On Tue, Aug 22, 2017 at 12:14 PM, Tudor Ambarus <tudor.amba...@microchip.com> wrote: Hi, Herbert, On 02/02/2017 03:57 PM, Herbert Xu wrote: Yes but RSA had an in-kernel user in the form of module signature verification. We don

  1   2   3   >