On 9/23/2013 4:28 PM, Nikos Mavrogiannopoulos wrote:
On 09/23/2013 02:31 PM, Horia Geantă wrote:
Hi,

CAAM crypto engine (drivers/crypto/caam/*) is capable of asymmetric
operations, like: modular exponentiation, RSA
sign/verify/encrypt/decrypt, (EC)DSA sign etc.
I would appreciate some design guidelines on how to harness these
capabilities, for crypto engines in general.

1. In-kernel interface for asymmetric crypto
Should crypto/asymmetric_keys/* be used, i.e. appended with modular
exponentiation, other asymmetric operations?
The BSD's cryptodev supports the following operations which may help in
that aspect (no elliptic curve operations present). I don't know if all
of them worth the context switch.

#define CRK_MOD_EXP             0
#define CRK_MOD_EXP_CRT         1
#define CRK_DSA_SIGN            2
#define CRK_DSA_VERIFY          3
#define CRK_DH_COMPUTE_KEY      4
#define CRK_MOD_ADD             5
#define CRK_MOD_ADDINV          6
#define CRK_MOD_SUB             7
#define CRK_MOD_MULT            8
#define CRK_MOD_MULTINV         9
#define CRK_MOD                 10

Thanks for the tip.
I took a look at BSD - AFAICT there is no SW implementation and crypto engine drivers handle only the first two operations (MOD_EXP).

My main concern now is the asymmetric ciphers API, that would eventually allow implementing the operations in SW/HW. I was wondering whether the same logic as for symmetric ciphers could/should be used (the API layering mentioned in Documentation/crypto/api-intro.txt). For example, crypto/asymmetric_keys/rsa.c could be registered and then used via Crypto API: rsa.c: crypto_alg->cra_name = "rsa"; crypto_alg->cra_driver_name="rsa-generic"; crypto_register_alg(crypto_alg);
user: tfm = crypto_alloc_tfm("rsa",...);
User would get either the "rsa-generic" SW implementation or a HW implementation, if available.


2. User space interface
Should AF_ALG be expanded to provide access to this new asymmetric cypto
API? The API would allow user space applications to offload PKC operations in
HW.
I'd be interested into adding this support into cryptodev-linux once
present in kernel.

Thanks.
We already have a draft implementation of asymmetric crypto + cryptodev-linux, but was developed prior to crypto/asymmetric_keys addition and thus has to be reworked.

Horia


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to