From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 3FF87FADD for ; Mon, 27 Mar 2017 14:59:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490619542; x=1522155542; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=v8p0tKtkktR4mqlDrwbYcLtasqsJsYhqCJr7uFokiNY=; b=ewIDN+2Bdy9oNKZXiuhM6PQ6Hvk9r8o3llGEyiKK2IGs4AQJdmq0vT+4 L+04xxeqh1xnRVxGdcOhAM+qVCYmJw==; Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 05:59:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,231,1486454400"; d="scan'208";a="81028544" Received: from dwdohert-mobl1.ger.corp.intel.com (HELO [163.33.228.196]) ([163.33.228.196]) by fmsmga005.fm.intel.com with ESMTP; 27 Mar 2017 05:58:59 -0700 To: Umesh Kartha , dev@dpdk.org References: <1490177802-13398-1-git-send-email-Umesh.Kartha@caviumnetworks.com> Cc: Jerin Jacob , Balasubramanian Manoharan , Ram Kumar , Murthy Nidadavolu , pablo.de.lara.guarch@intel.com From: Declan Doherty Message-ID: <8320df1a-9367-5f7a-528d-a64651600e95@intel.com> Date: Mon, 27 Mar 2017 13:58:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1490177802-13398-1-git-send-email-Umesh.Kartha@caviumnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] specifications for asymmetric crypto algorithms X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 12:59:02 -0000 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