On 22/03/2017 10:16 AM, Umesh Kartha wrote:
This RFC contains specifications for asymmetric crypto algorithms.
Asymmetric crypto algorithms are essential part of protocols such as
SSL/TLS. As the current DPDK crypto library lacks support for asymmetric
crypto algorithms, this RFC is an attempt to address it.
Cavium offers PCI hardware accelerators that supports symmetric and
asymmetric crypto algorithms, of which a few are addressed in this RFC.
Once specifications are agreed upon, I can submit a patch for the same.
We will develop a poll mode driver which can offload to OpenSSL crypto
library and to Cavium crypto accelerator.
The asymmetric crypto algorithms supported in this version are:
1 RSA
- RSA Sign
- RSA Verify
- RSA Public Encrypt
- RSA Private Decrypt
Padding schemes supported for RSA operations are
* RSA PKCS#1 BT1
* RSA PKCS#1 BT2
* RSA PKCS#1 OAEP
* RSA PKCS#1 PSS
2 ECDSA
- ECDSA Sign
- ECDSA Verify
Curves supported for ECDSA operations are
* Prime192v1
* Secp224k1
* Prime256v1
* Secp384r1
* Secp521r1
3 MODEXP
4 FUNDAMENTAL ECC
- Point Addition
- Point Multiplication
- Point Doubling
Curves supported for fundamental ECC operations are same as that of
ECDSA operations.
Asymmetric crypto transform operations support both session oriented
mode (WIP) and session less mode. If the operation is sessionless, an
asymmetric crypto transform structure, containing immutable parameters,
is passed along with per-operation mutable parameters in the structure.
Specific structures were written to contain immutable parameters
depending on algorithm used for crypto transform operation. The
parameters and type of transform is distinguished by the algorithm for
which the transform structure is filled. For a particular asymmetric
algorithm, not all parameters will be used and hence not required to be
filled.
Unlike symmetric operations, asymmetric operations can have more than
one resultant component for a single transform. Hence, only for select
operation types do we use destination mbuf structure passed along with
other operation parameters. The lengths of input and output parameters
are fixed and short. Depending on the algorithm, the number of inputs to
crypto transform operation, both mutable and immutable parameters,
vary. Depending on the algorithm, the type of data expected at source
mbuf varies and has been described.
---
...
Hey Umesh,
it's great to see this RFC and the expansion to the cryptodev framework
functionality. I'm currently working my way through the proposal and
drafting in some help from colleagues within Intel with asymmetric
crypto expertise. Hopefully I'll be able to come back to the list with
detailed comments as soon as possible.
Thanks
Declan
