Re: Transferring applied X.509 patches from crypto/next to security/next

On Tue, Feb 09, 2016 at 12:01:19PM +1100, James Morris wrote: > > > > If you can back them out, I'll apply them to my keys-next branch. Unless > > James is willing to rebase security/next on top of your crypto branch? > > > > I don't want to rebase my tree. OK, I've just reverted the patches a

[PATCH] crypto: fips: allow more ipsec related methods

IPSEC for aes-ctr requests: authenc(digest_null,rfc3686(ctr(aes))) which can be used in FIPS mode. rfc3686(ctr(aes)) is already allowed for FIPS usage. I also allowed "digest_null" for FIPS usage. Signed-off-by: Marcus Meissner --- crypto/testmgr.c | 5 + 1 file changed, 5 insert

Re: [PATCH 1/2] crypto: add asynchronous compression api

On Mon, Feb 08, 2016 at 04:10:02PM +, Giovanni Cabiddu wrote: > Signed-off-by: Giovanni Cabiddu This is missing the noctx support. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from thi

[PATCH] crypto: qat - Set ctx->e to NULL in qat_rsa_exit_tfm

Signed-off-by: Salvatore Benedetto --- drivers/crypto/qat/qat_common/qat_asym_algs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c b/drivers/crypto/qat/qat_common/qat_asym_algs.c index 51c594f..54e386e 100644 --- a/drivers/crypt

Re: [PATCH] crypto: qat - Set ctx->e to NULL in qat_rsa_exit_tfm

On Tue, Feb 09, 2016 at 11:21:35AM +, Salvatore Benedetto wrote: > Signed-off-by: Salvatore Benedetto We already use kzfree on the tfm, so we can get rid of all these manual zeroing. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.o

Re: [PATCH] crypto: fips: allow more ipsec related methods

Am Dienstag, 9. Februar 2016, 10:32:37 schrieb Marcus Meissner: Hi Marcus, >IPSEC for aes-ctr requests: > > authenc(digest_null,rfc3686(ctr(aes))) > >which can be used in FIPS mode. > >rfc3686(ctr(aes)) is already allowed for FIPS usage. > >I also allowed "digest_null" for FIPS usage. > >Si

[PATCH v2] crypto: xts - consolidate sanity check for keys

Hi, Changes v2: remove comment and remove FIPS ifdefs as requested by Ard Biesheuvel ---8<--- The patch centralizes the XTS key check logic into the service function xts_check_key which is invoked from the different XTS implementations. With this, the XTS implementations in ARM, ARM64, PPC and S

Re: Transferring applied X.509 patches from crypto/next to security/next

Herbert Xu wrote: > > > If you can back them out, I'll apply them to my keys-next branch. Unless > > > James is willing to rebase security/next on top of your crypto branch? > > > > > > > I don't want to rebase my tree. > > OK, I've just reverted the patches and pushed it out. Thanks. Can I

RE: RSA decryption output length

Thanks Tadeusz, The leading zeros are discarded in the process of conversion the byte array data to a big integer. When talking about numbers, the leading zeros are not meaningful. ta -Original Message- From: Tadeusz Struk [mailto:tadeusz.st...@intel.com] Sent: Friday, February 05, 20

Re: [PATCH v5 0/3] crypto: KEYS: convert public key to akcipher api

Are these in a public git branch somewhere that I can just merge? David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/3] crypto: KEYS: convert public key to akcipher api

On 02/09/2016 08:49 AM, David Howells wrote: > Are these in a public git branch somewhere that I can just merge? > No, after Herbert reverted them they only exist as separate patches: https://patchwork.kernel.org/patch/8193021/raw/ https://patchwork.kernel.org/patch/8193001/raw/ https://patchwork

[PATCH v2 2/2] crypto: extended acomp api for supporting deflate algorithm parameters

Signed-off-by: Giovanni Cabiddu --- crypto/acompress.c | 16 + include/crypto/acompress.h | 116 +++ include/crypto/internal/acompress.h | 24 +++ 3 files changed, 156 insertions(+), 0 deletions(-) diff --git a/crypto/acompre

[PATCH v2 1/2] crypto: add asynchronous compression api

Signed-off-by: Giovanni Cabiddu --- crypto/Kconfig | 10 + crypto/Makefile |2 + crypto/acompress.c | 118 + crypto/crypto_user.c| 21 +++ include/crypto/acompress.h | 322

[PATCH v2 0/2] crypto: asynchronous compression api

The following patch set introduces acomp, a generic asynchronous (de)compression api. What is proposed is a new crypto type called crypto_acomp_type, plus a new struct acomp_alg and struct crypto_acomp, together with number of helper functions to register acomp type algorithms and allocate tfm inst

Re: Transferring applied X.509 patches from crypto/next to security/next

On Tue, Feb 09, 2016 at 03:43:00PM +, David Howells wrote: > Herbert Xu wrote: > > > > > If you can back them out, I'll apply them to my keys-next branch. > > > > Unless > > > > James is willing to rebase security/next on top of your crypto branch? > > > > > > > > > > I don't want to reba

Crypto Fixes for 4.5

Hi Linus: This push fixes the following issues: API: * Fix async algif_skcipher, it was broken by recent fixes. * Fix potential race condition in algif_skcipher with ctx. * Fix potential memory corruption in algif_skcipher. * Add missing lock to crypto_user when doing an alg dump. Drivers: * m

[PATCH] vti6: Add pmtu handling to vti6_xmit.

http://www.spinics.net/lists/linux-crypto/msg15101.html > From: Steffen Klassert > > We currently rely on the PMTU discovery of xfrm. > However if a packet is localy sent, the PMTU mechanism > of xfrm tries to to local socket notification what > might not work for applications like ping that don't