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 Wed, May 6, 2015 at 12:36 PM, Tadeusz Struk tadeusz.st...@intel.com wrote:
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/Kconfig |6 +
crypto/Makefile|1
crypto/crypto_user.c | 24 +++
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
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 generation
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
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 two
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 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
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[3];
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
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 length argument.
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
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
>
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 defined in
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
interface
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
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
Herbert Xu herb...@gondor.apana.org.au 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?
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
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
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
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:
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
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
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_PKEY
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
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
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 herb...@gondor.apana.org.au
Herbert Xu herb...@gondor.apana.org.au 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.
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
at
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
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/Kconfig |6 +
crypto/Makefile|1
crypto/crypto_user.c | 24 +++
crypto/pkey.c | 125 ++
include/crypto/pkey.h | 390
34 matches
Mail list logo
