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

Resend v5 rebased on top of 4.5 This patch set converts the module verification and digital signature code to the new akcipher API. RSA implementation has been removed from crypto/asymmetric_keys and the new API is used for cryptographic primitives. There is no need for MPI above the akcipher API

[PATCH v5 3/3] crypto: public_key: remove MPIs from public_key_signature struct

After digsig_asymmetric.c is converted the MPIs can be now safely removed from the public_key_signature structure. Signed-off-by: Tadeusz Struk --- include/crypto/public_key.h | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git

[PATCH v5 1/3] crypto: KEYS: convert public key and digsig asym to the akcipher api

This patch converts the module verification code to the new akcipher API. Signed-off-by: Tadeusz Struk --- crypto/asymmetric_keys/Kconfig|2 crypto/asymmetric_keys/Makefile |7 - crypto/asymmetric_keys/pkcs7_parser.c | 12 +-

[PATCH v5 2/3] integrity: convert digsig to akcipher api

Convert asymmetric_verify to akcipher api. Signed-off-by: Tadeusz Struk --- security/integrity/Kconfig |1 + security/integrity/digsig_asymmetric.c | 10 +++--- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git

Re: [linux-sunxi] [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit

On Mon, Feb 01, 2016 at 05:39:21PM +, Andre Przywara wrote: > The driver for the sunxi-ss crypto engine is not entirely 64-bit safe, > compilation on arm64 spits some warnings. > The proper fix was deemed to involved [1], so since 64-bit SoCs won't > have this IP block we just disable this

Re: [PATCH v2 4/4] crypto: testmgr - Add a test case for import()/export()

On Tue, Feb 02, 2016 at 10:16:34PM +0800, Rui Wang wrote: > > I initially made it unconditional, but then I found that it can easily > hang the machine during boot due to any import/export bug in any of > the hash drivers. So I used this .partial flag to guard against this > risk. Only when an

Re: [PATCH v2 1/4] crypto x86/sha1_mb: Fix load failure

On Monday, February 1, 2016 4:18 PM, Herbert Xu wrote: > > On Wed, Jan 27, 2016 at 05:08:35PM +0800, Rui Wang wrote: >> >> +static int sha1_mb_async_import(struct ahash_request *req, const void >> +*in) { >> +struct ahash_request *mcryptd_req = ahash_request_ctx(req); >> +struct

Re: [PATCH v2 4/4] crypto: testmgr - Add a test case for import()/export()

On Mon, Feb 1, 2016 4:22 PM Herbert Xu wrote: > > On Wed, Jan 27, 2016 at 05:08:38PM +0800, Rui Wang wrote: > > > > diff --git a/crypto/testmgr.h b/crypto/testmgr.h index > > da0a8fd..451e7eb 100644 > > --- a/crypto/testmgr.h > > +++ b/crypto/testmgr.h > > @@ -44,6 +44,7 @@ struct hash_testvec {

Re: [RFC 1/2] crypto: tcrypt - Add acipher bandwidth tests support

On Tue, Feb 02, 2016 at 11:27:07AM +, Catalin Vasile wrote: > > >modprobe tcrypt mode=601 band=1> > Are you referring to modify the speed tests to include a flag to start > bandwidth tests? > If so, it sounds reasonable. Yes. Cheers, -- Email: Herbert Xu Home

Re: [PATCH v2 1/3] crypto: sahara - avoid needlessly saving and restoring sahara_ctx

On Tue, Feb 02, 2016 at 11:41:56AM -0200, Fabio Estevam wrote: > > static int sahara_sha_import(struct ahash_request *req, const void *in) > { > struct sahara_sha_reqctx *rctx = ahash_request_ctx(req); > > mutex_init(>mutex); > memcpy(rctx, in, sizeof(struct sahara_sha_reqctx));

Re: [PATCH v2 4/4] crypto: testmgr - Add a test case for import()/export()

On Tue, Feb 2, 2016 10:45 PM Herbert Xu wrote: > > On Tue, Feb 02, 2016 at 10:16:34PM +0800, Rui Wang wrote: > > > > I initially made it unconditional, but then I found that it can easily > > hang the machine during boot due to any import/export bug in any of > > the hash drivers. So I used this

Re: [RFC 1/2] crypto: tcrypt - Add acipher bandwidth tests support

>From: Herbert Xu >Sent: Monday, February 1, 2016 4:21 PM >To: Catalin Vasile >Cc: linux-crypto@vger.kernel.org; linux-crypto-ow...@vger.kernel.org; Horia >Ioan Geanta Neag; Cristian Stoica; Alexandru Porosanu; Catalin

Re: [PATCH v2 1/3] crypto: sahara - avoid needlessly saving and restoring sahara_ctx

Hi Herbert, On Mon, Jan 25, 2016 at 12:07 PM, Herbert Xu wrote: > Very good. Not only is it a waste, it's a gaping security hole > because modifying the tfm from import will corrupt it. > > But this is not enough, you're still copying things like the mutex > which

[PATCH v1] crypto: ccp - Don't assume export/import areas are aligned

Use a local variable for the exported and imported state so that alignment is not an issue. On export, set a local variable from the request context and then memcpy the contents of the local variable to the export memory area. On import, memcpy the import memory area into a local variable and then