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
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
> 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.
regards,
Nikos
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
On 09/27/2013 12:58 PM, Horia Geantă wrote:
> 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";
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