[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5133.1460757659@warthog.procyon.org.uk>
Date: Fri, 15 Apr 2016 23:00:59 +0100
From: David Howells <dhowells@...hat.com>
To: Tadeusz Struk <tadeusz.struk@...el.com>
Cc: dhowells@...hat.com, pjones@...hat.com, marcel@...tmann.org,
dwmw2@...radead.org, keyrings@...r.kernel.org,
linux-crypto@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org,
Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [RFC PATCH] KEYS: Provide keyctls to do public key operations
Tadeusz Struk <tadeusz.struk@...el.com> wrote:
> > --- a/crypto/asymmetric_keys/signature.c
> > +++ b/crypto/asymmetric_keys/signature.c
>
> Since this file implements the enc/dec operations also
> should it be renamed to crypto/asymmetric_keys/public_key_ops.c
> or something similar? signature.c is a bit confusing now.
Yes. Or maybe accessors.c. I'm also tempted to merge it into
asymmetric_type.c. One question is how many other ops we might want to add.
It might even be worth making the functions key_encrypt_blob(),
key_decrypt_blob(), key_create_signature() and key_verify_signature() and
jumping through the type ops table. I still haven't decided whether I want to
go to that extent yet as it leads to an extra function call on the stack.
> This will work perfectly for the algif_akcipher. Thanks for providing this.
> I'm going to rebase my patches on top of this and resend.
Note that this is a bit thrown together. I'm travelling right now and
conferencing next week which is why I haven't managed to test it yet - so
beware, there may be dragons;-)
> Should I use your keys-next as a base for the new version?
That's the base I used.
David
Powered by blists - more mailing lists