Re: [PATCH v11 0/2] crypto: AF_ALG memory management fix

On Fri, Jul 28, 2017 at 03:53:55PM +0200, Stephan Müller wrote: > > I would add the common service code to crypto/af_alg.c or do you prefer a > separate or different file? af_alg.c is OK. > As the copy-AAD patch is also outstanding, in which order would you like to > receive the patches (first

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote: > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote: > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote: > > > > > > Since there are two different user of "crypto engine + ablkcipher", it > > > will be not

Re: [PATCH v3 1/7] integrity: Introduce struct evm_hmac_xattr

Hi Thiago, On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote: > Even though struct evm_ima_xattr_data includes a fixed-size array to hold a > SHA1 digest, most of the code ignores the array and uses the struct to mean > "type indicator followed by data of unspecified size" and tracks

Re: [PATCH 0/4] Enable RSA Support on the CCP

On Mon, Jul 17, 2017 at 03:16:02PM -0500, Gary R Hook wrote: > This series accomplishes the following: > > - Fix RSA support in the base CCP driver > - Add the akcipher_set_reqsize() function > - Enable RSA support in the crypto layer > - Allow for a larger RSA modulus in a version 5 CCP > >

Re: [PATCH] crypto/rng: ensure that the RNG is ready before using

On Sun, Jul 16, 2017 at 07:22:06PM +0200, Jason A. Donenfeld wrote: > Otherwise, we might be seeding the RNG using bad randomness, which is > dangerous. The one use of this function from within the kernel -- not > from userspace -- is being removed (keys/big_key), so that call site > isn't

Re: [PATCH] crypto: ccp - Update copyright dates for 2017.

On Mon, Jul 17, 2017 at 03:00:49PM -0500, Gary R Hook wrote: > Some updates this year have not had copyright dates changed in modified > files. Correct this for 2017. > > Signed-off-by: Gary R Hook Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH v11 0/2] crypto: AF_ALG memory management fix

Am Freitag, 28. Juli 2017, 15:49:36 CEST schrieb Herbert Xu: Hi Herbert, > All patches applied. Yes please post follow-up patches to clean > up as necessary. Thank you. I will do that asap. I would add the common service code to crypto/af_alg.c or do you prefer a separate or different file?

Re: [PATCH 0/2] STM32 HASH crypto driver

On Thu, Jul 13, 2017 at 03:32:25PM +0200, Lionel Debieve wrote: > This set of patches adds a new crypto driver for STMicroelectronics stm32 HW. > This drivers uses the crypto API and provides with HW-enabled md5, sha1, > sha224, sha256 hash based algorithms. > It makes use of the crypto engine to

Re: [PATCH v2] crypto: caam - free qman_fq after kill_fq

On Thu, Jul 13, 2017 at 05:21:01AM -0400, Xulin Sun wrote: > kill_fq removes a complete frame queue, it needs to free the qman_fq > in the last. Else kmemleak will report the below warning: > > unreferenced object 0x800073085c80 (size 128): > comm "cryptomgr_test", pid 199, jiffies

Re: [PATCH 0/3] STM32 CRC update

On Thu, Jul 13, 2017 at 03:06:30PM +0200, Lionel Debieve wrote: > This set of patches update the STM32 CRC driver. > It contains two corrections and one global Kconfig rework. > First correction is about the relaxed usage in scope of arm > platform usage, second about a unbind driver issue. > Last

Re: [PATCH v11 0/2] crypto: AF_ALG memory management fix

On Sun, Jun 25, 2017 at 05:12:13PM +0200, Stephan Müller wrote: > Hi Herbert, > > Changes v11: > - algif_skcipher: remove len < ctx->used in recvmsg as requested by Herbert > and verified by the latest test code in libkcapi. > - algif_skcipher/algif_aead: simplify _recvmsg error code path > >

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

On Fri, Jul 28, 2017 at 09:52:57PM +0800, Herbert Xu wrote: > On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote: > > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote: > > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote: > > > > > > > > Since there are two

Re: KPP API and Temporary Keys

Am Freitag, 28. Juli 2017, 02:16:24 CEST schrieb Matt Corallo: Hi Matt, > Hi linux-crypto, > > Working on hacking together a tcpcrypt implementation which needs to use > KPP/ECDH based on new temporary keys for each new connections which uses > encryption. Sadly, the KPP API seems to be very

Re: KPP questions and confusion

Hi, Marcel, Kyle, On 07/17/2017 09:17 PM, Marcel Holtmann wrote: Hi Kyle, I am confused about several things in the new key agreement code. net/bluetooth/smp.c in two places generates random bytes for the private_key argument to net/bluetooth/ecdh_helper.c:generate_ecdh_keys, which suggests

Re: [RFC PATCH] crypto: caam - convert from ablkcipher -> skcipher

On 9/1/2016 1:13 PM, Herbert Xu wrote: > On Mon, Aug 29, 2016 at 05:11:24PM +0300, Horia Geantă wrote: >> (a)blkcipher is being deprecated in favcur of skcipher. >> The main difference is that IV generation is moved out >> of crypto algorithms. >> >> Signed-off-by: Horia Geantă

Crypto Fixes for 4.13

Hi Linus: This push fixes the following issues: - Remove broken dt bindings in inside-secure. - Fix authencesn crash when used with digest_null. - Fix cavium/nitrox firmware path. - Fix SHA3 failure in brcm. - Fix Kconfig dependency for brcm. Please pull from

Re: [RFC PATCH] crypto: caam - convert from ablkcipher -> skcipher

On Fri, Jul 28, 2017 at 06:46:03AM +, Horia Geantă wrote: > > If I am to add a new driver, would it be possible and/or advisable to > use skcipher? It should be OK. Let me know if you have any issues with the API. Thanks, -- Email: Herbert Xu Home Page:

Re: [PATCH 2/3] staging: ccree: Convert to devm_ioremap_resource for map, unmap

On Fri, Jul 28, 2017 at 09:59:41AM +0530, Suniel Mahesh wrote: > On Friday 28 July 2017 01:18 AM, Dan Carpenter wrote: > > On Thu, Jul 27, 2017 at 05:27:33PM +0300, Gilad Ben-Yossef wrote: > >> + new_drvdata->cc_base = devm_ioremap_resource(_dev->dev, > >> +

Re: [PATCH v2 3/3] crypto: scompress - defer allocation of scratch buffer to first use

On Wed, Jul 26, 2017 at 01:07:34AM +0100, Ard Biesheuvel wrote: > > > On 26 Jul 2017, at 00:36, Giovanni Cabiddu > > wrote: > > > > Hi Ard, > > > >> On Fri, Jul 21, 2017 at 04:42:38PM +0100, Ard Biesheuvel wrote: > >> +static int crypto_scomp_init_tfm(struct

Re: Fix dma unmap direction in iMX sahara aes calculation

Mogens Lauridsen wrote: > Hi, > > The direction used in dma_unmap_sg in aes calc in sahara.c is wrong. > This result in the cache not being invalidated correct when aes > calculation is done and result is dma'ed to memory. > This is seen as sporadic wrong result from aes

Re: KPP API and Temporary Keys

Yea, and while I understand this API is very useful for hardware accelerated (and, more often, secured) crypto and generally being very neatly pluggable, its, IMO, significantly less useful for many key agreement uses-cases. At least in the ever-more-used pattern of doing temporary key agreement

Re: KPP API and Temporary Keys

On Fri, Jul 28, 2017 at 4:00 PM, Matt Corallo wrote: > > Even worse, when I'm looking at tcpcrypt, not adding undue complication, > or, really, overhead, is a pretty important goal for something in the > tcp stack (especially for someone who doesn't know the TCP stack, and >

Re: KPP API and Temporary Keys

Hmm, fair, I hadn't considered the desire to pre-cache keys with the rest, in which case I suppose the existing API is likely about as good as you'd need (+/- duplicative extra tfm overhead, which annoys me, but likely isn't actually worth worrying about). I'll retract my criticism until I've