From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 18A90A0547; Mon, 8 Feb 2021 16:29:04 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 831961606BF; Mon, 8 Feb 2021 16:29:03 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id 7ABFA4014E for ; Mon, 8 Feb 2021 16:29:01 +0100 (CET) IronPort-SDR: pUsNe9Vvrm1Jtp/5uLPpVortgqNKiQSmu+ZOcJ+11dlTVTeSKUm+amQNPz5f+fNezBvytq4Z/i 1YxMN4VGn99w== X-IronPort-AV: E=McAfee;i="6000,8403,9889"; a="266560943" X-IronPort-AV: E=Sophos;i="5.81,162,1610438400"; d="scan'208";a="266560943" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2021 07:28:42 -0800 IronPort-SDR: 8GbJvb1VyxNZyWExF+GfDcLM6v2Q2tAN0wP9vqbxPp3rkCNNxD9xTkFYTEdocVpZTmbD7VK3Fc HkCqIVi8+qnA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,162,1610438400"; d="scan'208";a="509503976" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga004.jf.intel.com with ESMTP; 08 Feb 2021 07:28:40 -0800 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Feb 2021 07:28:39 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Mon, 8 Feb 2021 07:28:39 -0800 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.171) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Mon, 8 Feb 2021 07:28:38 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QMRbUKdtx4NnUDjr6e14aeSG6nNWioA4poSXelbzmllW5Wv6LU59/YTDlRNer8qdRtTBZm8RlmvRV5nLlp6KmatnTwT1ppq/MBHos2FEiBc2pIifviwtd3RdNqSHulRDXcW+kucbXKtCJm0LVWyoj3gMBcIdrlRWiU6ZV/oaeBvjmowqHbzGrsDB2qGd8Hvgw2Vey9G5moKVkbBOLkB4T4I/goV3j4in/r5zPZgBBggDErZ3vtZBFBvOs1cluTIoY7EbvfymkzwdoXlBaDe9CUpoTx4V3ibYclQCHH7igmqrpaPaHqXTip1brmnXjpC4QiedvUKkVePUbeiGHOYE4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8f5sR2N4D9Y7kMyO6/B8xgLaI6paYfRefLqOL23r7L4=; b=d/449IAr6WnRqA/d3Ewv1FwIDWMZR1Y0jkxr/v7mt4VAEYOY1ZMiMAW8f/aLlJfIbnaYNln/RXNZiftu1BUjVQsKjnVdJGpFyjh/Ps37HgKVXTH0dE02VzD46LnO3WKqzPxVxRtoeNHhfyiq7WZL6vG2nzer2kfBVshmBzUxySwJiVcMOXafhLsvmEhHrDYq5FvDKVPjEOuWoBTza+cYwRG70BntMjOjvM/Qxw7GuQ1YBmfaBbiviZc3EQxsxD3HkZOSr/C294+1KVbJEmcOJI7OgBr5QrqoYPF8OtOksLmnd/mM0Irs8AlAYVXHXqpQXNgPEQubQOYKlJPsZ+nWeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8f5sR2N4D9Y7kMyO6/B8xgLaI6paYfRefLqOL23r7L4=; b=IIMlGB4U368Knh0WZ9tcysYB27vBLx3VCI6scNwj1gRjotqiexk+RC/WZx2Qi4824ReLK0thOJzQCkNhVNIRfJ6ebQ7L4BzY/j+slj14TrWfCOr0Y3QgREEYcaMoAuAOkpTlBE3eLAtXY02T0Z0BaPiiIrgSBELDcQhNIa/eCHI= Received: from CY4PR11MB1830.namprd11.prod.outlook.com (2603:10b6:903:125::21) by CY4PR1101MB2295.namprd11.prod.outlook.com (2603:10b6:910:19::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.17; Mon, 8 Feb 2021 15:28:36 +0000 Received: from CY4PR11MB1830.namprd11.prod.outlook.com ([fe80::918d:fda8:f181:1af0]) by CY4PR11MB1830.namprd11.prod.outlook.com ([fe80::918d:fda8:f181:1af0%3]) with mapi id 15.20.3825.030; Mon, 8 Feb 2021 15:28:36 +0000 From: "Kusztal, ArkadiuszX" To: Matan Azrad , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "Doherty, Declan" , Somalapuram Amaranath , Ruifeng Wang , Ajit Khaparde , Anoob Joseph , "Zhang, Roy Fan" , "Griffin, John" , "De Lara Guarch, Pablo" , Michael Shamis , Nagadheeraj Rottela , Ankur Dwivedi , Gagandeep Singh , "Jay Zhou" Thread-Topic: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes Thread-Index: AQHW+wL0hikMeVRrxE2cpoYyRSs5mKpOCI/wgABAXACAAAP80A== Date: Mon, 8 Feb 2021 15:28:36 +0000 Message-ID: References: <1612449252-395208-1-git-send-email-matan@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.151.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e171d924-fdb5-4ce9-28af-08d8cc46342b x-ms-traffictypediagnostic: CY4PR1101MB2295: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: r6IgILFzYyFJjJ6iV5kMHf8bm/4pT85bO7xJtMFjRD7Av6lzXtVkHbKN38+4Sk+WwGTd9jQla5HUEtEb+AlLawDJ75lbzcaMDDzHbGjFRLiVztTAOr2sYVABmtYAQAcIFvBhjXQYyVjhFwcnAz6o0hMMpEPYaEghY9B8r+7WOpttgSPyZyhaii0TqJMSRsXpgEKAG0tdip09eNlaNr7MjZTmE/Bm7lT0tmCCyJn/Aj/JOYe8tV1MuSCfIt8qC8cwTmITzLN4R/HJKYImfPkWfRCfhziLtaE+vfAqzP8s8paOJl5rbNTQ0sFeNONOjN8ysOQH3hBC0Q4WaJWo3TR1KYnfIDvY23MKUOJyHUdlq4HESc8gy335IpjHRk2Gdb5ImLxIjPA+9NtmZjdN/4pbCyPtDe0v+y9eXZA+R6z0sNVaOzjH7GBZvmbk6fN1746Sfag47x5JO5nkQdKafese1rGs4MELZdSea5rq+o89vhlLn+ctgmhiqPTXY1hqmT7RGlszF07khbCIGvcJq+7dsA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR11MB1830.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(396003)(376002)(136003)(366004)(66946007)(66476007)(66556008)(186003)(66446008)(64756008)(55016002)(7696005)(26005)(76116006)(478600001)(9686003)(6506007)(52536014)(4326008)(5660300002)(110136005)(54906003)(316002)(8936002)(33656002)(83380400001)(86362001)(7416002)(71200400001)(8676002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?YLsuDhASfdNTTYGrbF0Mvnsms5szNAKoHfAG44bbg1HIDZsindd47IRLnsYa?= =?us-ascii?Q?MORsc+llpXDVL20u4j6mBnOBGW3GRkVw6S6ydC/po9jk4cPVrUYNOi5byxBH?= =?us-ascii?Q?Pcu8vRZes6/zxJIyo/FDBcY7hPXPx7WKBw5uGK2URN+BI5MNVIl4slGCJBLV?= =?us-ascii?Q?dTBfpPUUbAtlKe7Ng+2gX2Hk7Cyrv6FWijxv2tUMVj4Lpc6HcoGBEWyzWc+I?= =?us-ascii?Q?nFLH0SPM3Jzhv6ll9gEynMSxXtA57n9+1oUZvHzLipz5/EzTUIR92u5xeUS5?= =?us-ascii?Q?nr4VPDUl6hLt14e4uxLj7gyG7NoafAo0Zke1EIlHoRb+XqGkHU3Tc3G+krAz?= =?us-ascii?Q?da+bOuOkwpp2UpDjLj0oqhiG1XAJZPCPT+tcwhGEFV4ZK/UlozG2uBCiN9Ta?= =?us-ascii?Q?h231t3qi0wcYcWxajuuUMjh1339KWZH9oo1HwNfx6/2XPnCD/ikCbDJK91ay?= =?us-ascii?Q?1Np2nCM0+OH681QhPz6egiWw/wH5hYeHmgdSFfsXWN2BVgqfJahYpcvB7Wnw?= =?us-ascii?Q?eT2PQLNk4vfH5WlT9mjr8G1JUlUq2+79D4BfITKhoj5nEDf5f7wmcOKp+oVe?= =?us-ascii?Q?5cUxLe4C5iiwx5qco919WHB1dj8UxpaTDCZKiEwQE3hXzRWdzEbrUjfzB8wI?= =?us-ascii?Q?NigwtyddMkRWXgX60b5wLvNFeRvFsAyU404VOvkqy1Gb1QYeOqgD9qUt8i6E?= =?us-ascii?Q?0vT4zhQtL+mQPD6be4ZOrhSvDzvpSbzPFR4yU4s+/PMapbEaaV4qq0QyReb5?= =?us-ascii?Q?pSFGNXc22rAGs93IIp9nuioQ79rT+N0ao38ltFCCs+RpLT3SLzS2CCsHBD2t?= =?us-ascii?Q?FF60vywetpzEARVDIJah6GOldY6foOTW6XOYNyTsqJ2UPVTk6eT+6NxmAZNC?= =?us-ascii?Q?SKBzHy0sq+R9AR6oTeJHvaIzT9uN+Iy2unSCrkhm4vXFu1i9oSRk/MEmvtrW?= =?us-ascii?Q?r41bpE4B3g4/XOv06FDIsMfN6E8Y3PZaTbTwlRsg0AAI0TZ6OAthf9NL9lLl?= =?us-ascii?Q?htwtif84BQ2faQvCH8YEJdTdun2j/EQcUmOU1s7svp9KoyqCWdQ4q2IkZnkW?= =?us-ascii?Q?OJYREWdi5yBiu7A3clv883CwJRj/pGJLX02NvqnyovB69elshab3S1shiGor?= =?us-ascii?Q?p94UyznFb8zvMzbicvgSKJA5bqEMI0qgiVxDqv7qifNe2cHy6tuqLkoUzpuE?= =?us-ascii?Q?tMye5j8okrZfZ0+4Z4Q/T/7U/GfCFv/LBswxOyBoo3rkra/6tntBBSPoP1HG?= =?us-ascii?Q?LoH3z62ZwknTCZ0kPVJpSQU5ZjgYQ8fbmLm2u17v52sE2yMx201Qcjy1+3+M?= =?us-ascii?Q?pFgawNtekhr2op1ws4BymnBS?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB1830.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e171d924-fdb5-4ce9-28af-08d8cc46342b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2021 15:28:36.6456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Yl3ar4xJ+sz48iJ54FSABEtWNf3xc+dkmhIXWlsRUI4QFIrVFfIiX23q2b0dApVXyRSNCr6g9F9tbUh2qJCRcf9wQISgIPZnoJa5jPuVlKo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2295 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > > > Subject: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block > > > sizes > > > > > > In cryptography, a block cipher is a deterministic algorithm > > > operating on fixed- length groups of bits, called blocks. > > > > > > A block cipher consists of two paired algorithms, one for encryption > > > and the other for decryption. Both algorithms accept two inputs: > > > an input block of size n bits and a key of size k bits; and both > > > yield an n-bit output block. The decryption algorithm is defined to > > > be the inverse function of the encryption. > > > > > > Some cipher algorithms support multiple block sizes, e.g. AES-XTS > > > supports any block size in range [16B, 2^24B], in this case, A > > > plain-text data, divided into N amount of n-bits blocks, which is > > > encrypted to the same data size, cipher-text, must be decrypted in > > > the same division of N amount of n-bits blocks in order to get the > > > same plain-text > > data. > > [Arek] - Except that the last data block does not need to be n-bit > > long, beside that and lack of chaining it makes XTS no different to > > any other block cipher mode of operation. > > Block size itself for XTS-AES is always 16 bytes in the first place > > which is AES constraint. > > 2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is data > > unit length that contains "data unit in bytes/ 16" AES blocks where > > last one can be incomplete. > > > > > > > > The current cryptodev API doesn't allow the user to select a > > > specific block size supported by the devices In addition, there is > > > no definition how the IV is detected per block when single operation > > > includes > > more than one block. > > > > [Arek] - Do you mean tweak increment per data unit? Like one op as a > > data stream (multiple data units) and tweak incremented by pmd? >=20 > It can be defined differently per algorithm. [Arek] - what do you mean? > I know from AES-XTS standard that the tweak should be incremented by 1 pe= r > data-unit. > So, yes, here, the driver\device should take care for the incrementation. [Arek] - then it should be stated in rte_crypto_sym_op iv comments. >=20 >=20 > > > > > > > > That causes applications to use single operation per block even > > > though all the data is continuous in memory what reduces datapath > performance. > > > > > > Add a new feature flag to support multiple block sizes, called > > > RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS. > > > Add a new field in cipher capability, called bsf - block size flags, > > > where the devices can report the range of the supported block sizes. > > > Add a new cipher transformation field, called block_size, where the > > > user can select one block size from the supported range. > > > > > > All the new fields do not change the size of their structures. > > > > > > Using flags to report the supported block sizes capability allows > > > the devices to report a range simply as same as the user to read it s= imply. > > > Also, thus sizes are usually common and probably will be shared > > > between the devices. > > > > > > Signed-off-by: Matan Azrad > > > --- > > > lib/librte_cryptodev/rte_crypto_sym.h | 12 ++++++++++++ > > > lib/librte_cryptodev/rte_cryptodev.h | 23 ++++++++++++++++++++++- > > > 2 files changed, 34 insertions(+), 1 deletion(-) > > > > > > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h > > > b/lib/librte_cryptodev/rte_crypto_sym.h > > > index 9d572ec..9a1215d 100644 > > > --- a/lib/librte_cryptodev/rte_crypto_sym.h > > > +++ b/lib/librte_cryptodev/rte_crypto_sym.h > > > @@ -265,6 +265,18 @@ struct rte_crypto_cipher_xform { > > > * which can be in the range 7 to 13 inclusive. > > > */ > > > } iv; /**< Initialisation vector parameters */ > > > + > > > + uint32_t block_size; [Arek] - looking from your answers below, this one could just be aes_xts_da= taunit_len. > > > + /**< When RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS is > > > reported, this is > > > + * the block size of the algorithm, otherwise or when the value= is 0, > > > + * use the default block size provided in the capability. > > > + * The value should be in the range defined by the bsf field in= the > > > + * cipher capability. > > > > [Arek] - nowadays algorithms rather don't have different block sizes, > > though I see people set this field even for stream ciphers. > > If such algorithm would happen it probably could just get a suffix in > > crypto_cipher_enum. Otherwise some fixed size array could be added. >=20 > First, if no different block size per algorithm, why do we need this para= meter at > all? [Arek] - I am not sure but looks like informative, especially that it is on= ly one 16bit long field. =20 >=20 > Second, > Cipher block defined to be like this D(E(b)) =3D b > D: decryption function > E: encryption function > P: plain-text block data. >=20 > In case of AES-XTS the cipher block size is the data-unit size. > There is a big range of optional data, see in standard. [Arek] - Currently in DPDK we have 3 block cipher algorithms: TDEA(3DES) - 8 byte block, AES - 16 byte block, KASUMI -8byte (but deprecat= ed since 3G), Additionally IPsec ietf defines NULL as block cipher with 1 byte len, but E= TSI doesn't do that with EEA,EIA,NIA-0. >=20 >=20 > > > + * > > > + * - For AES-XTS it is the size of data-unit, from IEEE Std 161= 9-2007. > > > + * For-each data-unit in the operation, the tweak(IV) value is > > > + * assigned consecutively starting from the operation assigned = tweak. > > > + */ > > [Arek] - if data unit would be session value (key scope in xts naming) > > where the number of units would be taken from, sym_op->len ? >=20 > Yes, it is already defined there that it must be multiple of block size(d= ata-unit in > AES-XTS case). [Arek] - this comment was meant for cipher block modes that needs input al= igned to block cipher len, like CBC padding. In case of XTS it should be something like : multiple of xform xts_data_uni= t len or one of two: - data unit len itself in case device does not support multiple data units. - 0 and data unit len would be taken from session/xform in case device does= not support multiple data units. >=20 > > (For standard storage example: data unit size -> logical block size, > > sym_op->len > > -> range of consecutive logical blocks.) If so it probably could be > > -> session-less op > > as this cipher key would be unusable after it. > > >=20 > Can be session and session-less modes. >=20 > If the user want to operate on different groups of blocks in the same str= eam he > can use the same session(key) with different ops. [Arek] - yes, it should be possible to do that if user keep track of tweak = value. >=20 > Am I missing here? >=20 > > > }; > > > > > > /** Symmetric Authentication / Hash Algorithms diff --git > > > a/lib/librte_cryptodev/rte_cryptodev.h > > > b/lib/librte_cryptodev/rte_cryptodev.h > > > index ae34f33..60ba839 100644 > > > --- a/lib/librte_cryptodev/rte_cryptodev.h > > > +++ b/lib/librte_cryptodev/rte_cryptodev.h > > > @@ -96,6 +96,19 @@ struct rte_crypto_param_range { }; > > > > > > /** > > > + * Crypto device supported block size flags for cipher algorithms > > > + * Each flag represents single or range of supported block sizes > > > +*/ #define RTE_CRYPTO_CIPHER_BSF_ALL 0x1 > > > +/* All the sizes from the algorithm standard */ #define > > > +RTE_CRYPTO_CIPHER_BSF_512_BYTES 0x2 #define > > > +RTE_CRYPTO_CIPHER_BSF_520_BYTES 0x4 #define > > > +RTE_CRYPTO_CIPHER_BSF_4048_BYTES 0x8 #define > > > +RTE_CRYPTO_CIPHER_BSF_4096_BYTES 0x10 #define > > > +RTE_CRYPTO_CIPHER_BSF_4160_BYTES 0x20 #define > > > +RTE_CRYPTO_CIPHER_BSF_1M_BYTES 0x40 > > [Arek] - when adding constants source should be attached as well. > > > + > > > +/** > > > * Symmetric Crypto Capability > > > */ > > > struct rte_cryptodev_symmetric_capability { @@ -122,11 +135,19 @@ > > > struct rte_cryptodev_symmetric_capability { > > > enum rte_crypto_cipher_algorithm algo; > > > /**< cipher algorithm */ > > > uint16_t block_size; > > > - /**< algorithm block size */ > > > + /**< > > > + * algorithm block size > > > + * For algorithms support more than single bloc= k size, > > > + * this is the default block size supported by = the > > > + * driver, all the supported sizes are reflecte= d in the > > > + * bsf field. > > > + */ > > > struct rte_crypto_param_range key_size; > > > /**< cipher key size range */ > > > struct rte_crypto_param_range iv_size; > > > /**< Initialisation vector data size range */ > > > + uint32_t bsf; > > > + /**< Block size flags */ > > > } cipher; > > > /**< Symmetric Cipher transform capabilities */ > > > struct { > > > -- > > > 1.8.3.1