On Wed, May 6, 2015 at 12:36 PM, Tadeusz Struk wrote:
> Add Public Key Encryption API.
>
> Signed-off-by: Tadeusz Struk
> ---
> crypto/Kconfig |6 +
> crypto/Makefile|1
> crypto/crypto_user.c | 24 +++
> crypto/pkey.c | 125 ++
>
On 05/31/2015 10:48 PM, Herbert Xu wrote:
> On Thu, May 28, 2015 at 09:54:41AM -0700, Tadeusz Struk wrote:
>>
>> If we do this that way then we will be able to pass only one input and one
>> output parameter. There are cases when we will need more that this.
>> For instance for ECDSA signature gene
On Thu, May 28, 2015 at 09:54:41AM -0700, Tadeusz Struk wrote:
>
> If we do this that way then we will be able to pass only one input and one
> output parameter. There are cases when we will need more that this.
> For instance for ECDSA signature generation we need one input param hash(m)
> and tw
On 05/27/2015 09:08 PM, Herbert Xu wrote:
> Do you have a specific piece of hardware in mind? What are its
> capabilities?
I'm going to use it with Intel's DH985xcc accelerator. It can accelerate
RSA, DH, ECDSA and ECDH just to name the most commonly used.
But I don't want to add anything that is
On Sat, May 23, 2015 at 07:20:15AM -0700, Tadeusz Struk wrote:
>
> The length would be redundant. It can be obtained by sg_nents(reg->inparams)
> I don't limit the number of parameters. You can pass as many as you want. For
> instance to pass 3 in and 2 out you do:
>
> struct scatterlist in
On 05/22/2015 10:47 PM, Herbert Xu wrote:
>> struct akcipher_request {
>> >struct crypto_async_request base;
>> >struct scatterlist *inparams;
>> >struct scatterlist *outparams;
>> >void *__ctx[] CRYPTO_MINALIGN_ATTR;
>> > };
> I think you should rename them to src/dst and add a len
On Fri, May 22, 2015 at 11:37:49AM -0700, Tadeusz Struk wrote:
>
> /**
> * struct akcipher_request - public key request
> *
> * @base: Common attributes for async crypto requests
> * @inparams: scatterlist of input parameters (one ent per parameter)
> *for the operation as defi
On 05/10/2015 11:32 PM, Herbert Xu wrote:
> On Wed, May 06, 2015 at 12:36:48PM -0700, Tadeusz Struk wrote:
>>
>> +const struct public_key_signature *signature;
>
> Doing this means that you aren't adding it to the crypto API
> properly. You need to start from scratch and design a proper
> int
On Wed, May 13, 2015 at 04:03:55PM +0100, David Howells wrote:
>
> So what if we want to use a key that's stored in a TPM? I presume then we
> can't use the crypto interface, but must rather use the *key* as the primary
> interface somehow.
Then it has nothing to do with what we're trying to do h
Herbert Xu wrote:
> > What if the fallback doesn't exist? For instance, a H/W contained key is
> > specifically limited to, say, just sign/verify and the not permitted to be
> > used for encrypt/decrypt. How do you provide a fallback given you can't get
> > at the key?
>
> That's a transform w
On Mon, May 11, 2015 at 02:45:27PM +0100, David Howells wrote:
>
> What if the fallback doesn't exist? For instance, a H/W contained key is
> specifically limited to, say, just sign/verify and the not permitted to be
> used for encrypt/decrypt. How do you provide a fallback given you can't get
>
Herbert Xu wrote:
> > + * @capabilities:
> > + * Specifies what operations are provided by the algorithm
> > + * implementation.
>
> Don't do this. It's a nightmare for the user to have to deal with
> multiple implementations with differing capabilities.
>
> Make the implemento
On Wed, May 06, 2015 at 12:36:48PM -0700, Tadeusz Struk wrote:
>
> + const struct public_key_signature *signature;
Doing this means that you aren't adding it to the crypto API
properly. You need to start from scratch and design a proper
interface and not just wrap some existing opaque data st
On Wed, May 06, 2015 at 12:36:48PM -0700, Tadeusz Struk wrote:
>
> +struct pkey_request {
> + struct crypto_async_request base;
> + const struct public_key *pkey;
The key should not come from the request. It should go into the
tfm.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.
On Wed, May 06, 2015 at 12:36:48PM -0700, Tadeusz Struk wrote:
> + * @capabilities:
> + * Specifies what operations are provided by the algorithm
> + * implementation.
Don't do this. It's a nightmare for the user to have to deal with
multiple implementations with differing cap
On Wed, May 06, 2015 at 12:36:48PM -0700, Tadeusz Struk wrote:
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 8aaf298..daa9c07 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -87,6 +87,12 @@ config CRYPTO_PCOMP2
> tristate
> select CRYPTO_ALGAPI2
>
> +config CRYPTO
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig |6 +
crypto/Makefile|1
crypto/crypto_user.c | 24 +++
crypto/pkey.c | 125 ++
include/crypto/pkey.h | 390
17 matches
Mail list logo
