Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
On 5/4/2015 11:42 PM, Tadeusz Struk wrote: > Hi Horia, > On 05/04/2015 06:16 AM, Horia Geantă wrote: >>> int (*sign)(struct pke_request *pkereq); int (*verify)(struct pke_request *pkereq); int (*encrypt)(struct pke_request *pkereq); int (*decrypt)(struct pke_request *pkereq); >> Where would be the proper place for keygen operation? > > This will need to be extended to support keygen. > >> >> AFAICT algorithms currently map to primitives + encoding methods, which >> is not flexible. For e.g. current RSA implementation hardcodes the >> PKCS1-v1_5 encoding method, making it hard to add OAEP(+) etc. >> >> One solution would be to map algorithms to primitives only. Encoding >> methods need to be abstracted somehow, maybe using templates to wrap the >> algorithms. > > So far there is only one rsa implementation in kernel and it is only used > by module signing code. > Later we can add templates or simply one can register "oaep-rsa" algorithm. I am thinking that it would be more logical for "rsa" to represent only the *primitives*, for e.g. RSASP1, RSAVP1, RSAEP, RSADP (in rfc3447 terminology). Then pkcs1_v15(rsa), oaep(rsa), pss(rsa) (i.e. RSAES-PKCS1-v1_5, RSAES-OAEP, RSASSA-PSS encryption and/or signature schemes) would share the primitives implementation, the only thing that would differ being the encoding/padding method. This is similar to symmetric ciphers convention of having the mode defined as a wrapper: we have cbc(aes), ctr(aes), gcm(aes) and not cbc-aes, ctr-aes, gcm-aes. Another thing to consider is that there might be crypto engines which are able to perform only "textbook" rsa. This would allow for the primitives to be offloaded, while the encoding methods would be performed in SW. Thanks, Horia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
On 5/4/2015 11:42 PM, Tadeusz Struk wrote: Hi Horia, On 05/04/2015 06:16 AM, Horia Geantă wrote: int (*sign)(struct pke_request *pkereq); int (*verify)(struct pke_request *pkereq); int (*encrypt)(struct pke_request *pkereq); int (*decrypt)(struct pke_request *pkereq); Where would be the proper place for keygen operation? This will need to be extended to support keygen. AFAICT algorithms currently map to primitives + encoding methods, which is not flexible. For e.g. current RSA implementation hardcodes the PKCS1-v1_5 encoding method, making it hard to add OAEP(+) etc. One solution would be to map algorithms to primitives only. Encoding methods need to be abstracted somehow, maybe using templates to wrap the algorithms. So far there is only one rsa implementation in kernel and it is only used by module signing code. Later we can add templates or simply one can register oaep-rsa algorithm. I am thinking that it would be more logical for rsa to represent only the *primitives*, for e.g. RSASP1, RSAVP1, RSAEP, RSADP (in rfc3447 terminology). Then pkcs1_v15(rsa), oaep(rsa), pss(rsa) (i.e. RSAES-PKCS1-v1_5, RSAES-OAEP, RSASSA-PSS encryption and/or signature schemes) would share the primitives implementation, the only thing that would differ being the encoding/padding method. This is similar to symmetric ciphers convention of having the mode defined as a wrapper: we have cbc(aes), ctr(aes), gcm(aes) and not cbc-aes, ctr-aes, gcm-aes. Another thing to consider is that there might be crypto engines which are able to perform only textbook rsa. This would allow for the primitives to be offloaded, while the encoding methods would be performed in SW. Thanks, Horia -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
Hi Horia, On 05/04/2015 06:16 AM, Horia Geantă wrote: >> int (*sign)(struct pke_request *pkereq); >> >int (*verify)(struct pke_request *pkereq); >> >int (*encrypt)(struct pke_request *pkereq); >> >int (*decrypt)(struct pke_request *pkereq); > Where would be the proper place for keygen operation? This will need to be extended to support keygen. > > AFAICT algorithms currently map to primitives + encoding methods, which > is not flexible. For e.g. current RSA implementation hardcodes the > PKCS1-v1_5 encoding method, making it hard to add OAEP(+) etc. > > One solution would be to map algorithms to primitives only. Encoding > methods need to be abstracted somehow, maybe using templates to wrap the > algorithms. So far there is only one rsa implementation in kernel and it is only used by module signing code. Later we can add templates or simply one can register "oaep-rsa" algorithm. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
On 5/1/2015 1:36 AM, Tadeusz Struk wrote:
> This patch set introduces a Public Key Encryption API.
> What is proposed is a new crypto type called crypto_pke_type
> plus new struct pke_alg and struct pke_tfm together with number
> of helper functions to register pke type algorithms and allocate
> tfm instances. This is to make it similar to how the existing crypto
> API works for the ablkcipher, ahash, and aead types.
> The operations the new interface will allow to provide are:
>
> int (*sign)(struct pke_request *pkereq);
> int (*verify)(struct pke_request *pkereq);
> int (*encrypt)(struct pke_request *pkereq);
> int (*decrypt)(struct pke_request *pkereq);
Where would be the proper place for keygen operation?
>
> The benefits it gives comparing to the struct public_key_algorithm
> interface are:
> - drivers can add many implementations of RSA or DSA
> algorithms and user will allocate instances (tfms) of these, base on
> algorithm priority, in the same way as it is with the symmetric ciphers.
> - the new interface allows for asynchronous implementations that
> can use crypto hardware to offload the calculations to.
> - integrating it with linux crypto api allows using all its benefits
> i.e. managing algorithms using NETLINK_CRYPTO, monitoring implementations
> using /proc/crypto. etc
>
> New helper functions have been added to allocate pke_tfm instances
> and invoke the operations to make it easier to use.
> For instance to verify a public_signature against a public_key using
> the RSA algorithm a user would do:
>
> struct crypto_pke *tfm = crypto_alloc_pke("rsa", 0, 0);
> struct pke_request *req = pke_request_alloc(tfm, GFP_KERNEL);
> pke_request_set_crypt(req, pub_key, signature);
> int ret = crypto_pke_verify(req);
> pke_request_free(req);
> crypto_free_pke(tfm);
> return ret;
>
> Additionally existing public_key and rsa code have been reworked to
> use the new interface for verifying signed modules.
> As part of the rework the enum pkey_algo has been removed as the algorithm
> to allocate will be indicated by a string - for instance "rsa" or "dsa",
> similarly as it is with the symmetric algs e.g. "aes".
> It will also make it easier to extend in the future when new algorithms
> will be added.
AFAICT algorithms currently map to primitives + encoding methods, which
is not flexible. For e.g. current RSA implementation hardcodes the
PKCS1-v1_5 encoding method, making it hard to add OAEP(+) etc.
One solution would be to map algorithms to primitives only. Encoding
methods need to be abstracted somehow, maybe using templates to wrap the
algorithms.
Regards,
Horia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
On 5/1/2015 1:36 AM, Tadeusz Struk wrote: This patch set introduces a Public Key Encryption API. What is proposed is a new crypto type called crypto_pke_type plus new struct pke_alg and struct pke_tfm together with number of helper functions to register pke type algorithms and allocate tfm instances. This is to make it similar to how the existing crypto API works for the ablkcipher, ahash, and aead types. The operations the new interface will allow to provide are: int (*sign)(struct pke_request *pkereq); int (*verify)(struct pke_request *pkereq); int (*encrypt)(struct pke_request *pkereq); int (*decrypt)(struct pke_request *pkereq); Where would be the proper place for keygen operation? The benefits it gives comparing to the struct public_key_algorithm interface are: - drivers can add many implementations of RSA or DSA algorithms and user will allocate instances (tfms) of these, base on algorithm priority, in the same way as it is with the symmetric ciphers. - the new interface allows for asynchronous implementations that can use crypto hardware to offload the calculations to. - integrating it with linux crypto api allows using all its benefits i.e. managing algorithms using NETLINK_CRYPTO, monitoring implementations using /proc/crypto. etc New helper functions have been added to allocate pke_tfm instances and invoke the operations to make it easier to use. For instance to verify a public_signature against a public_key using the RSA algorithm a user would do: struct crypto_pke *tfm = crypto_alloc_pke(rsa, 0, 0); struct pke_request *req = pke_request_alloc(tfm, GFP_KERNEL); pke_request_set_crypt(req, pub_key, signature); int ret = crypto_pke_verify(req); pke_request_free(req); crypto_free_pke(tfm); return ret; Additionally existing public_key and rsa code have been reworked to use the new interface for verifying signed modules. As part of the rework the enum pkey_algo has been removed as the algorithm to allocate will be indicated by a string - for instance rsa or dsa, similarly as it is with the symmetric algs e.g. aes. It will also make it easier to extend in the future when new algorithms will be added. AFAICT algorithms currently map to primitives + encoding methods, which is not flexible. For e.g. current RSA implementation hardcodes the PKCS1-v1_5 encoding method, making it hard to add OAEP(+) etc. One solution would be to map algorithms to primitives only. Encoding methods need to be abstracted somehow, maybe using templates to wrap the algorithms. Regards, Horia -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
Hi Horia, On 05/04/2015 06:16 AM, Horia Geantă wrote: int (*sign)(struct pke_request *pkereq); int (*verify)(struct pke_request *pkereq); int (*encrypt)(struct pke_request *pkereq); int (*decrypt)(struct pke_request *pkereq); Where would be the proper place for keygen operation? This will need to be extended to support keygen. AFAICT algorithms currently map to primitives + encoding methods, which is not flexible. For e.g. current RSA implementation hardcodes the PKCS1-v1_5 encoding method, making it hard to add OAEP(+) etc. One solution would be to map algorithms to primitives only. Encoding methods need to be abstracted somehow, maybe using templates to wrap the algorithms. So far there is only one rsa implementation in kernel and it is only used by module signing code. Later we can add templates or simply one can register oaep-rsa algorithm. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
On 05/01/2015 01:47 AM, Jean Delvare wrote: > I have nothing to do with this, please drop me from Cc. Sorry, your name was reported by scripts/get_maintainer.pl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
Tadeusz Struk wrote: > As part of the rework the enum pkey_algo has been removed as the algorithm > to allocate will be indicated by a string - for instance "rsa" or "dsa", No. That number is exposed outside of the kernel. Actually, if you can integrate: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7 then we can replace the exposed number with OIDs. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
I have nothing to do with this, please drop me from Cc.
Thanks,
Jean
On Thu, 30 Apr 2015 15:36:47 -0700, Tadeusz Struk wrote:
> This patch set introduces a Public Key Encryption API.
> What is proposed is a new crypto type called crypto_pke_type
> plus new struct pke_alg and struct pke_tfm together with number
> of helper functions to register pke type algorithms and allocate
> tfm instances. This is to make it similar to how the existing crypto
> API works for the ablkcipher, ahash, and aead types.
> The operations the new interface will allow to provide are:
>
> int (*sign)(struct pke_request *pkereq);
> int (*verify)(struct pke_request *pkereq);
> int (*encrypt)(struct pke_request *pkereq);
> int (*decrypt)(struct pke_request *pkereq);
>
> The benefits it gives comparing to the struct public_key_algorithm
> interface are:
> - drivers can add many implementations of RSA or DSA
> algorithms and user will allocate instances (tfms) of these, base on
> algorithm priority, in the same way as it is with the symmetric ciphers.
> - the new interface allows for asynchronous implementations that
> can use crypto hardware to offload the calculations to.
> - integrating it with linux crypto api allows using all its benefits
> i.e. managing algorithms using NETLINK_CRYPTO, monitoring implementations
> using /proc/crypto. etc
>
> New helper functions have been added to allocate pke_tfm instances
> and invoke the operations to make it easier to use.
> For instance to verify a public_signature against a public_key using
> the RSA algorithm a user would do:
>
> struct crypto_pke *tfm = crypto_alloc_pke("rsa", 0, 0);
> struct pke_request *req = pke_request_alloc(tfm, GFP_KERNEL);
> pke_request_set_crypt(req, pub_key, signature);
> int ret = crypto_pke_verify(req);
> pke_request_free(req);
> crypto_free_pke(tfm);
> return ret;
>
> Additionally existing public_key and rsa code have been reworked to
> use the new interface for verifying signed modules.
> As part of the rework the enum pkey_algo has been removed as the algorithm
> to allocate will be indicated by a string - for instance "rsa" or "dsa",
> similarly as it is with the symmetric algs e.g. "aes".
> It will also make it easier to extend in the future when new algorithms
> will be added.
> ---
> Tadeusz Struk (2):
> crypto: add PKE API
> crypto: RSA: KEYS: convert rsa and public key to new PKE API
>
>
> Documentation/crypto/asymmetric-keys.txt | 10 +-
> crypto/Kconfig|6 +
> crypto/Makefile |1
> crypto/asymmetric_keys/Kconfig|1
> crypto/asymmetric_keys/pkcs7_parser.c |4 -
> crypto/asymmetric_keys/pkcs7_trust.c |2
> crypto/asymmetric_keys/pkcs7_verify.c |5 -
> crypto/asymmetric_keys/public_key.c | 73 +++
> crypto/asymmetric_keys/public_key.h | 36 -
> crypto/asymmetric_keys/rsa.c | 47 ++-
> crypto/asymmetric_keys/x509_cert_parser.c | 14 ++
> crypto/asymmetric_keys/x509_public_key.c | 14 +-
> crypto/crypto_user.c | 23 +++
> crypto/pke.c | 114 +
> include/crypto/algapi.h |6 +
> include/crypto/public_key.h | 24 +---
> include/linux/crypto.h| 191
> +
> include/linux/cryptouser.h|7 +
> kernel/module_signing.c |9 +
> 19 files changed, 471 insertions(+), 116 deletions(-)
> delete mode 100644 crypto/asymmetric_keys/public_key.h
> create mode 100644 crypto/pke.c
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
Tadeusz Struk tadeusz.st...@intel.com wrote: As part of the rework the enum pkey_algo has been removed as the algorithm to allocate will be indicated by a string - for instance rsa or dsa, No. That number is exposed outside of the kernel. Actually, if you can integrate: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7 then we can replace the exposed number with OIDs. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
On 05/01/2015 01:47 AM, Jean Delvare wrote: I have nothing to do with this, please drop me from Cc. Sorry, your name was reported by scripts/get_maintainer.pl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
I have nothing to do with this, please drop me from Cc. Thanks, Jean On Thu, 30 Apr 2015 15:36:47 -0700, Tadeusz Struk wrote: This patch set introduces a Public Key Encryption API. What is proposed is a new crypto type called crypto_pke_type plus new struct pke_alg and struct pke_tfm together with number of helper functions to register pke type algorithms and allocate tfm instances. This is to make it similar to how the existing crypto API works for the ablkcipher, ahash, and aead types. The operations the new interface will allow to provide are: int (*sign)(struct pke_request *pkereq); int (*verify)(struct pke_request *pkereq); int (*encrypt)(struct pke_request *pkereq); int (*decrypt)(struct pke_request *pkereq); The benefits it gives comparing to the struct public_key_algorithm interface are: - drivers can add many implementations of RSA or DSA algorithms and user will allocate instances (tfms) of these, base on algorithm priority, in the same way as it is with the symmetric ciphers. - the new interface allows for asynchronous implementations that can use crypto hardware to offload the calculations to. - integrating it with linux crypto api allows using all its benefits i.e. managing algorithms using NETLINK_CRYPTO, monitoring implementations using /proc/crypto. etc New helper functions have been added to allocate pke_tfm instances and invoke the operations to make it easier to use. For instance to verify a public_signature against a public_key using the RSA algorithm a user would do: struct crypto_pke *tfm = crypto_alloc_pke(rsa, 0, 0); struct pke_request *req = pke_request_alloc(tfm, GFP_KERNEL); pke_request_set_crypt(req, pub_key, signature); int ret = crypto_pke_verify(req); pke_request_free(req); crypto_free_pke(tfm); return ret; Additionally existing public_key and rsa code have been reworked to use the new interface for verifying signed modules. As part of the rework the enum pkey_algo has been removed as the algorithm to allocate will be indicated by a string - for instance rsa or dsa, similarly as it is with the symmetric algs e.g. aes. It will also make it easier to extend in the future when new algorithms will be added. --- Tadeusz Struk (2): crypto: add PKE API crypto: RSA: KEYS: convert rsa and public key to new PKE API Documentation/crypto/asymmetric-keys.txt | 10 +- crypto/Kconfig|6 + crypto/Makefile |1 crypto/asymmetric_keys/Kconfig|1 crypto/asymmetric_keys/pkcs7_parser.c |4 - crypto/asymmetric_keys/pkcs7_trust.c |2 crypto/asymmetric_keys/pkcs7_verify.c |5 - crypto/asymmetric_keys/public_key.c | 73 +++ crypto/asymmetric_keys/public_key.h | 36 - crypto/asymmetric_keys/rsa.c | 47 ++- crypto/asymmetric_keys/x509_cert_parser.c | 14 ++ crypto/asymmetric_keys/x509_public_key.c | 14 +- crypto/crypto_user.c | 23 +++ crypto/pke.c | 114 + include/crypto/algapi.h |6 + include/crypto/public_key.h | 24 +--- include/linux/crypto.h| 191 + include/linux/cryptouser.h|7 + kernel/module_signing.c |9 + 19 files changed, 471 insertions(+), 116 deletions(-) delete mode 100644 crypto/asymmetric_keys/public_key.h create mode 100644 crypto/pke.c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
This patch set introduces a Public Key Encryption API.
What is proposed is a new crypto type called crypto_pke_type
plus new struct pke_alg and struct pke_tfm together with number
of helper functions to register pke type algorithms and allocate
tfm instances. This is to make it similar to how the existing crypto
API works for the ablkcipher, ahash, and aead types.
The operations the new interface will allow to provide are:
int (*sign)(struct pke_request *pkereq);
int (*verify)(struct pke_request *pkereq);
int (*encrypt)(struct pke_request *pkereq);
int (*decrypt)(struct pke_request *pkereq);
The benefits it gives comparing to the struct public_key_algorithm
interface are:
- drivers can add many implementations of RSA or DSA
algorithms and user will allocate instances (tfms) of these, base on
algorithm priority, in the same way as it is with the symmetric ciphers.
- the new interface allows for asynchronous implementations that
can use crypto hardware to offload the calculations to.
- integrating it with linux crypto api allows using all its benefits
i.e. managing algorithms using NETLINK_CRYPTO, monitoring implementations
using /proc/crypto. etc
New helper functions have been added to allocate pke_tfm instances
and invoke the operations to make it easier to use.
For instance to verify a public_signature against a public_key using
the RSA algorithm a user would do:
struct crypto_pke *tfm = crypto_alloc_pke("rsa", 0, 0);
struct pke_request *req = pke_request_alloc(tfm, GFP_KERNEL);
pke_request_set_crypt(req, pub_key, signature);
int ret = crypto_pke_verify(req);
pke_request_free(req);
crypto_free_pke(tfm);
return ret;
Additionally existing public_key and rsa code have been reworked to
use the new interface for verifying signed modules.
As part of the rework the enum pkey_algo has been removed as the algorithm
to allocate will be indicated by a string - for instance "rsa" or "dsa",
similarly as it is with the symmetric algs e.g. "aes".
It will also make it easier to extend in the future when new algorithms
will be added.
---
Tadeusz Struk (2):
crypto: add PKE API
crypto: RSA: KEYS: convert rsa and public key to new PKE API
Documentation/crypto/asymmetric-keys.txt | 10 +-
crypto/Kconfig|6 +
crypto/Makefile |1
crypto/asymmetric_keys/Kconfig|1
crypto/asymmetric_keys/pkcs7_parser.c |4 -
crypto/asymmetric_keys/pkcs7_trust.c |2
crypto/asymmetric_keys/pkcs7_verify.c |5 -
crypto/asymmetric_keys/public_key.c | 73 +++
crypto/asymmetric_keys/public_key.h | 36 -
crypto/asymmetric_keys/rsa.c | 47 ++-
crypto/asymmetric_keys/x509_cert_parser.c | 14 ++
crypto/asymmetric_keys/x509_public_key.c | 14 +-
crypto/crypto_user.c | 23 +++
crypto/pke.c | 114 +
include/crypto/algapi.h |6 +
include/crypto/public_key.h | 24 +---
include/linux/crypto.h| 191 +
include/linux/cryptouser.h|7 +
kernel/module_signing.c |9 +
19 files changed, 471 insertions(+), 116 deletions(-)
delete mode 100644 crypto/asymmetric_keys/public_key.h
create mode 100644 crypto/pke.c
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
This patch set introduces a Public Key Encryption API. What is proposed is a new crypto type called crypto_pke_type plus new struct pke_alg and struct pke_tfm together with number of helper functions to register pke type algorithms and allocate tfm instances. This is to make it similar to how the existing crypto API works for the ablkcipher, ahash, and aead types. The operations the new interface will allow to provide are: int (*sign)(struct pke_request *pkereq); int (*verify)(struct pke_request *pkereq); int (*encrypt)(struct pke_request *pkereq); int (*decrypt)(struct pke_request *pkereq); The benefits it gives comparing to the struct public_key_algorithm interface are: - drivers can add many implementations of RSA or DSA algorithms and user will allocate instances (tfms) of these, base on algorithm priority, in the same way as it is with the symmetric ciphers. - the new interface allows for asynchronous implementations that can use crypto hardware to offload the calculations to. - integrating it with linux crypto api allows using all its benefits i.e. managing algorithms using NETLINK_CRYPTO, monitoring implementations using /proc/crypto. etc New helper functions have been added to allocate pke_tfm instances and invoke the operations to make it easier to use. For instance to verify a public_signature against a public_key using the RSA algorithm a user would do: struct crypto_pke *tfm = crypto_alloc_pke(rsa, 0, 0); struct pke_request *req = pke_request_alloc(tfm, GFP_KERNEL); pke_request_set_crypt(req, pub_key, signature); int ret = crypto_pke_verify(req); pke_request_free(req); crypto_free_pke(tfm); return ret; Additionally existing public_key and rsa code have been reworked to use the new interface for verifying signed modules. As part of the rework the enum pkey_algo has been removed as the algorithm to allocate will be indicated by a string - for instance rsa or dsa, similarly as it is with the symmetric algs e.g. aes. It will also make it easier to extend in the future when new algorithms will be added. --- Tadeusz Struk (2): crypto: add PKE API crypto: RSA: KEYS: convert rsa and public key to new PKE API Documentation/crypto/asymmetric-keys.txt | 10 +- crypto/Kconfig|6 + crypto/Makefile |1 crypto/asymmetric_keys/Kconfig|1 crypto/asymmetric_keys/pkcs7_parser.c |4 - crypto/asymmetric_keys/pkcs7_trust.c |2 crypto/asymmetric_keys/pkcs7_verify.c |5 - crypto/asymmetric_keys/public_key.c | 73 +++ crypto/asymmetric_keys/public_key.h | 36 - crypto/asymmetric_keys/rsa.c | 47 ++- crypto/asymmetric_keys/x509_cert_parser.c | 14 ++ crypto/asymmetric_keys/x509_public_key.c | 14 +- crypto/crypto_user.c | 23 +++ crypto/pke.c | 114 + include/crypto/algapi.h |6 + include/crypto/public_key.h | 24 +--- include/linux/crypto.h| 191 + include/linux/cryptouser.h|7 + kernel/module_signing.c |9 + 19 files changed, 471 insertions(+), 116 deletions(-) delete mode 100644 crypto/asymmetric_keys/public_key.h create mode 100644 crypto/pke.c -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
