[dpdk-dev] [RFC] specifications for asymmetric crypto algorithms

[Declan Doherty]

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