Asymmetric cryptography HW offloading

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? I am asking since this seems to be closer to key management than to asymmetric crypto...
If so, should an algorithm priority be defined, similar to Crypto API interface for symmetric algos (so that for e.g. a HW implementation of RSA verify would be preferred over a SW implementation)? Currently interface does not allow for two or more implementers of the same algo/operation.

Currently, SW implementation of modular exponentiation - mpi_powm() - is used by crypto/asymmetric_keys/rsa.c and lib/digsig.c. AFAICT, its users could benefit from a HW-accelerated version.

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. Possible use: offloading compute-intensive parts of TLS handshake, IKE.

Thanks,
Horia

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

I'd be interested into adding this support into cryptodev-linux once present in kernel.

regards,
Nikos

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.

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

As RSA fits into the encryption API it may be just ok. I'd say do it and then we see whether that API causes some bottleneck for asymmetric encryption. But how would you fit modexp in that case?

Having the expensive big number operations could be useful to non-crypto number crunching projects as well (e.g. gmp and its users).

regards,
Nikos