[dpdk-dev] [RFC PATCH v2 1/3] cryptodev: added asymmetric algorithms

Umesh Kartha Umesh.Kartha at caviumnetworks.com
Fri Jun 2 13:01:14 CEST 2017


Hi Fiona,

On Mon, May 29, 2017 at 02:51:11PM +0000, Trahe, Fiona wrote:
> Hi Umesh,
> 
> > -----Original Message-----
> > From: Umesh Kartha [mailto:Umesh.Kartha at caviumnetworks.com]
> > Sent: Friday, May 26, 2017 8:18 AM
> > To: Trahe, Fiona <fiona.trahe at intel.com>
> > Cc: dev at dpdk.org; Jerin Jacob <Jerin.JacobKollanukkaran at cavium.com>; Balasubramanian Manoharan
> > <Balasubramanian.Manoharan at cavium.com>; Ram Kumar <Ram.Kumar at cavium.com>; Murthy
> > Nidadavolu <Nidadavolu.Murthy at cavium.com>; Doherty, Declan <declan.doherty at intel.com>; De Lara
> > Guarch, Pablo <pablo.de.lara.guarch at intel.com>
> > Subject: Re: [RFC PATCH v2 1/3] cryptodev: added asymmetric algorithms
> > 
> > Hi Fiona,
> > 
> > 
> > On Thu, May 25, 2017 at 04:00:42PM +0000, Trahe, Fiona wrote:
> > > Hi Umesh,
> > >
> > >
> > > > -----Original Message-----
> > > > From: Umesh Kartha [mailto:Umesh.Kartha at caviumnetworks.com]
> > > > Sent: Thursday, May 11, 2017 1:36 PM
> > > > To: dev at dpdk.org
> > > > Cc: Jerin Jacob <Jerin.JacobKollanukkaran at cavium.com>; Balasubramanian Manoharan
> > > > <Balasubramanian.Manoharan at cavium.com>; Ram Kumar <Ram.Kumar at cavium.com>; Murthy
> > > > Nidadavolu <Nidadavolu.Murthy at cavium.com>; Doherty, Declan <declan.doherty at intel.com>; De
> > Lara
> > > > Guarch, Pablo <pablo.de.lara.guarch at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>
> > > > Subject: [RFC PATCH v2 1/3] cryptodev: added asymmetric algorithms
> > > >
> > > > Added asymmetric xform structures, operation definitions, operation
> > > > parameters. Added asymmetric algorithms RSA, DH, ECDH, DSA, ECDSA,
> > > > MODEXP, FECC, MOD-INVERSE. Added curves (all curves supported by
> > > > libcrypto as of now).
> > > >
> > > > Signed-off-by: Umesh Kartha <Umesh.Kartha at caviumnetworks.com>
> > > > ---
> > > >  lib/librte_cryptodev/rte_crypto_asym.h | 1124 ++++++++++++++++++++++++++++++++
> > > >  1 file changed, 1124 insertions(+)
> > > >  create mode 100644 lib/librte_cryptodev/rte_crypto_asym.h
> > > >
> > > > diff --git lib/librte_cryptodev/rte_crypto_asym.h lib/librte_cryptodev/rte_crypto_asym.h
> > > > new file mode 100644
> > > > index 0000000..36a8b4f
> > > > --- /dev/null
> > > > +++ lib/librte_cryptodev/rte_crypto_asym.h
> > > > @@ -0,0 +1,1124 @@
> > > > +/*
> > > > + *   BSD LICENSE
> > > > + *
> > > > + *   Copyright (C) Cavium networks Ltd. 2017.
> > > > + *
> > > > + *   Redistribution and use in source and binary forms, with or without
> > > > + *   modification, are permitted provided that the following conditions
> > > > + *   are met:
> > > > + *
> > > > + *     * Redistributions of source code must retain the above copyright
> > > > + *       notice, this list of conditions and the following disclaimer.
> > > > + *     * Redistributions in binary form must reproduce the above copyright
> > > > + *       notice, this list of conditions and the following disclaimer in
> > > > + *       the documentation and/or other materials provided with the
> > > > + *       distribution.
> > > > + *     * Neither the name of Cavium Networks nor the names of its
> > > > + *       contributors may be used to endorse or promote products derived
> > > > + *       from this software without specific prior written permission.
> > > > + *
> > > > + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> > > > + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > > > + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> > > > + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> > > > + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> > > > + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> > > > + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> > > > + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> > > > + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > > > + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> > > > + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > > > + */
> > > > +
> > > > +#ifndef _RTE_CRYPTO_ASYM_H_
> > > > +#define _RTE_CRYPTO_ASYM_H_
> > > > +
> > > > +/**
> > > > + * @file rte_crypto_asym.h
> > > > + *
> > > > + * RTE Definitions for Asymmetric Cryptography
> > > > + *
> > > > + * Defines asymmetric algorithms and modes, as well as supported
> > > > + * asymmetric crypto operations.
> > > > + */
> > > > +
> > > > +#ifdef __cplusplus
> > > > +extern "C" {
> > > > +#endif
> > > > +
> > > > +#include <string.h>
> > > > +#include <stdint.h>
> > > > +#include <rte_mbuf.h>
> > > > +#include <rte_memory.h>
> > > > +#include <rte_mempool.h>
> > > > +#include <rte_common.h>
> > > > +#include "rte_crypto_sym.h"
> > > > +
> > > > +typedef struct rte_crypto_xform_param_t {
> > > > +	uint8_t *data;
> > > > +	size_t length;
> > > > +} rte_crypto_xform_param;
> > > > +
> > > > +typedef struct rte_crypto_op_param_t {
> > > > +	uint8_t *data;
> > > > +	phys_addr_t phys_addr;
> > > > +	size_t length;
> > > > +} rte_crypto_op_param;
> > > [Fiona] Are both above lengths in bytes ?
> > >
> > >
> > [Umesh] Yes, they are in bytes. Will add note for this to avoid any
> > confusion.
> [Fiona] Thanks.
> Re your v1 question re sessionless, I don't see a strong need to support sessions
> in Asymm crypto and we would probably initially just implement the SESSIONLESS case.
> For that case, the rte_crypto_xform_param_t would be used to provide data to
> the op. So providing a phys_addr would save an internal alloc and copy and 
> be necessary to optimise performance. 
> What do you think of adding this?
> In that case the structs are identical, so can be combined. 
> 
> Regards,
> Fiona
> 

If the general conscience is that a session is not required to perform
asymmetric crypto operations, I will remove it. The only scenario in which
an asymmetric session can be used is to generate DSA/ECDSA/RSA signatures
multiple times. Alternatively, crypto_asym_xform struct can be reused in
this scenario.
And yes, as you suggested, we can combine the structs.


Regards,
Umesh


More information about the dev mailing list