Asymmetric cryptography HW offloading

Asymmetric cryptography HW offloading

[Horia Geantă]

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

Re: Asymmetric cryptography HW offloading

[Nikos Mavrogiannopoulos]

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

Re: Asymmetric cryptography HW offloading

[Horia Geantă]

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

Re: Asymmetric cryptography HW offloading

[Nikos Mavrogiannopoulos]

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