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 +-
crypto/asymmetric_keys/pkcs7_trus
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 a/security/integrity/Kconfig b/security/integrity/Kc
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 a/include/crypto/public_key.h b/inclu
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
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
On Tue, Feb 2, 2016 at 12:43 PM, Herbert Xu wrote:
> Preferably you shouldn't include the mutex in the exported state
> at all.
Ok, so would it be safe to completely remove the mutex like this?
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -182,7 +182,6 @@ struct sahara_sha_req
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 .p
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 Page: http://gondor.apana.org.
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 auth
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(&rctx->mutex);
> memcpy(rctx, in, sizeof(struct sahara_sha_reqctx));
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 {
>
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 crypto_ah
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 should not be copied but inste
>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 Vasile
>Subject: Re: [RFC 1/2] cryp
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 driv
15 matches
Mail list logo