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 544CBA054F; Mon, 1 Mar 2021 10:29:12 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E1BAE4067B; Mon, 1 Mar 2021 10:29:11 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id EB0C44014E for ; Mon, 1 Mar 2021 10:29:09 +0100 (CET) IronPort-SDR: 1k8pUiK/NZq1CaMgs99QNmFKidoHLiHrSPLAbQxICEFy8oW6cCxTVLDrZ8+lL9dnITSULQ/WVe 4jpGl4gNofvg== X-IronPort-AV: E=McAfee;i="6000,8403,9909"; a="173539472" X-IronPort-AV: E=Sophos;i="5.81,215,1610438400"; d="scan'208";a="173539472" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2021 01:29:08 -0800 IronPort-SDR: TT/1p9/hWUewE1XlBhSi+78qjfPeNfawWMucw3MKVvey/Yq1h2QIcNcMgNCVy8yehb/EVb7jJI drQkqxF0koPA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,215,1610438400"; d="scan'208";a="397645066" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga008.fm.intel.com with ESMTP; 01 Mar 2021 01:29:06 -0800 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 1 Mar 2021 01:29:05 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx604.amr.corp.intel.com (10.18.126.84) 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, 1 Mar 2021 01:29:05 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Mon, 1 Mar 2021 01:29:05 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XA5yI6l1bHO0MaX/9OPEpcEn5PMiZm+q6iQvaqqeFsqgp0pph2cVI98Udug4x3KlHy1B647zehMqAW48ok8pUxcjwJGhXCT39KVBJvO5mjbPvz+J33zZmQ4OtVNMm25ghZztLUUBKLPAKMHZNLgFnCDWpSA67cCtVI0Sk1YYmXFiTYZdVVS8Oswg0e2r7a2CecB833hPJxSmVlLLC3Et96BpyoewyvJJdrMLkMrwuJRDYqFQwnsecQZe31cqJ6/r8vwC+X4JI9E/pv64cQVd7QGGjUTlOP/2hMs4mg+ocCacbIgmaQV3b3M9lq9AczULmFBO47beA4WrDtJ3bGpL+w== 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=F+mn3ifV5H1dpaTejfkbGtFpg2zj4ZUmGI0iZhGje4I=; b=dmRkzI39Cr1AASigKelHdLds5Jkhhuqj50AwqvmLPdwUh7vZYxqqt2dwZ30x5CoamoaAnNdb/c3yi0KO0QHU1PzsZ4MNtEhG/B68UT7E8BzrLj7y+fgElGH5ZMzbjdMNWhyrLdMcVEXL4BRKUCcpoaovsEBHqsIk8Og20m5d0xP1yzgcog5rtLc8y0ZsNTsE8D445N1qBOgtQQfDLW2z0xMcM9sYZsjy1yFvL5nuswrmtGNgMlsVDyseSCsqKWnqWOqDqgm4xQKFB7AWm+6i4R6JZzqbHK2wmLDgbEB1I87paf41q1KIwG92IQLTSNfSj2niQZ468AxMSzFj2NG2YQ== 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=F+mn3ifV5H1dpaTejfkbGtFpg2zj4ZUmGI0iZhGje4I=; b=G3ss8d8WOasdFbiYolsDD875jCRU8CsaXiCKmKKgur3gvk1eJqdPg6MW0Ox11fjr3le+cruSuwSDD5ISu1N8GWCibA+b9Azy+oWsJbDB2iHMhCjQUafi34f3S9EcjPZc0iiDTRTKw6t9YHKbALJhDt66iov45csAiBw8WNQ1ELw= Received: from CY4PR11MB1830.namprd11.prod.outlook.com (2603:10b6:903:125::21) by CY4PR11MB2008.namprd11.prod.outlook.com (2603:10b6:903:22::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.28; Mon, 1 Mar 2021 09:29:03 +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.3890.028; Mon, 1 Mar 2021 09:29:03 +0000 From: "Kusztal, ArkadiuszX" To: Matan Azrad , Anoob Joseph , "dev@dpdk.org" CC: "Doherty, Declan" , Somalapuram Amaranath , Ruifeng Wang , Ajit Khaparde , "Zhang, Roy Fan" , "Griffin, John" , "De Lara Guarch, Pablo" , Michael Shamis , Nagadheeraj Rottela , Ankur Dwivedi , Gagandeep Singh , Jay Zhou , Akhil Goyal , "Jerin Jacob Kollanukkaran" Thread-Topic: [EXT] [PATCH] cryptodev: support multiple cipher block sizes Thread-Index: AQHXC/yEvQXrbPJQ/UqvP3VhP5p1+qpuyJqAgAAYBYA= Date: Mon, 1 Mar 2021 09:29:02 +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.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50877143-fff3-4911-a216-08d8dc9473f9 x-ms-traffictypediagnostic: CY4PR11MB2008: 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: k+4h8vfjDmdWaYtaURvQByxaHR22rfmDH36S/EL5iTuN1PgEa2HhyLmHv4xbjvmFk/w2d6CCaVTvG3Al+8Rx5sf3rkw6kx8c94ywcHSeuebj3CCOibICEXGMiwGBvbsN6/MmYfVVf9VXn5zlhnFuWbvB8fzlEj7u/F6bupvTFAxNgQfy0slURUqXrknV4Kjf1eACTq8hVRr0F2VfsJN4+P6HsVIw5InPwBe7frSgBv+dX6MiEYFVrgzYhVWO9VvGC2qxeIfwGnoNa7I869+VBPiCr8vDuojEm79BRCMlSy/4PpMjlrEBaF184W8Zj7e1WQS68hRIjeTcuLXI9ArMYJmJ4xFcMso2KOTNx1B33E5Grn2mPZkCLG7qvEqS3idF8CDfGvCbRJPDG6bt3JXNg7kznGy5d4nbxYFJeQO++5GS1FFpr7q4ct/edJWxES5L4Q008Dm6JWmlokF+rsgM4snd1REcvBzxb4NxragNHMebPxGNa6jKprAuLCxZcDNxXXPUnKhDXKqWvl5KD5iO2Q== 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:(396003)(39860400002)(376002)(366004)(346002)(136003)(53546011)(478600001)(26005)(66476007)(71200400001)(6506007)(4326008)(66556008)(66446008)(64756008)(186003)(9686003)(5660300002)(52536014)(66946007)(55016002)(7696005)(76116006)(7416002)(316002)(83380400001)(110136005)(8676002)(86362001)(8936002)(54906003)(33656002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?/zXaJYgrGCz3aAl1SBDMxEjh52e8gZwFMUkZbW7ZvDx+P/oYURUPcNlO6Sbd?= =?us-ascii?Q?MXldNhs78mQRqYXD0630+YvSJkuMBOEWU+V5K2kHfTm3k240dXszKU+hg53v?= =?us-ascii?Q?wsATnekwLgk6yKTXGmbGXkpX16JJhxEKb0hjSK+IGYQzJO2mC8189dJiZy6g?= =?us-ascii?Q?6fRoaRkfRItpZgP8aTigymtRhm2/IIAH470sTMe2LJIFtODPp7GT13Z0DVdg?= =?us-ascii?Q?2cji6+YBQryKMqf8rIgQWfv0pnl8U2f0thBWlmy2ozxlqIB9LvdFBWZ9KJk1?= =?us-ascii?Q?mq+gDQFMJ4BZAXIkzduBRRHyfbAg2+Hy+ViUbgA9KaT3Iht2dry0XNmV4f0q?= =?us-ascii?Q?HcENH/lezlYgm6mG2bTkvt60iUeaVXtiod+VKxrWM18tifn+GESCWqdapTjZ?= =?us-ascii?Q?4az9jO9Wirl7i3oSt5l0IzIL/Yg9OFnV4k85Vr4UI/+KUazuvaSkmPQpszRC?= =?us-ascii?Q?9rEt1lMWgUdMizD8fa4XjKOtJ5KiMRWq1u8t5TmeiXcbPyOSBovZHCcDqAMh?= =?us-ascii?Q?eKs582oXB5Yk8DZ1k1qAOfS0xpxybtEzbwEmhcOsuduiTE9VB/TrfzEXTE8T?= =?us-ascii?Q?cCOO+RjLP/avsiSXteoLj3sp5FRdmZlcYP+zlVL6kuLB/jjio2JpKSShKxY0?= =?us-ascii?Q?EK5m7XHQQfSUxFhnvDO24lETn+1UbmX2quL2+iKRnvDCWZ3NW86YcKsXmYML?= =?us-ascii?Q?3oEbimkoHHNJph3Mv8HiFBQBioip4+8uoRVnseid5TA1KNLpgaTLUClGn9y/?= =?us-ascii?Q?LqsOJSBbghIs6xJ1Ss5LKiu/rvnSiHoAewHoqC67GlmvNGgdsNDxAoa3TWX0?= =?us-ascii?Q?QaUvkgMmLtsQFGrcFka5c10eiClXiFleRJSFJKlWhn+8caA+zdOJ/IBv0FJu?= =?us-ascii?Q?CQUTiHzT+G2b7XDMhWmcRwNDx7xL1xhmw93HfFkYK0K4toVBq61ctV3J+ELc?= =?us-ascii?Q?/K3ISg9BD7L5v6rmhtQ6u9Nx1yOkeNxTtV39bVVBHKaYbuUcSDG1w3yiHgL9?= =?us-ascii?Q?A4CrpjKqyw2pIX4LjBmMklW1Ds67MQy9NrdH4r3mULHN/s4GuY9F6kTioa4l?= =?us-ascii?Q?to6BV9UwqT1T4+M3oSEXzPXK4shG70XQMso2dBJx3TdfhpqM6rT+IWqCtWDv?= =?us-ascii?Q?k/v+0ELuou8j7liddcVekkpTvWYDZgxs8PKeIMYa2AqqlJGiHPRoPewqebF9?= =?us-ascii?Q?a3P+HTmL4xnHUREXOgAfbG43QspasO1IJb5D2JVE4oyEPErWuAwc9feat3/0?= =?us-ascii?Q?jExfXeA3NdSV/ymJOYDYZaLZxA6sfcaPPEUAiCVyMGdSnkfsIMzkSK2lJc2g?= =?us-ascii?Q?nF1uZcplbePSGJEVRzX2AHxB?= 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: 50877143-fff3-4911-a216-08d8dc9473f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2021 09:29:02.9146 (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: G4wDfjbCeoK33ZWNqXcosuWTF6zxwszLDinIRPHJMz5v86cS5zjB7OvMrRmBezx3dynXi09/QcnNb4rIwF8k2r+F6gAju3Y8v+IH4OU/P1s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB2008 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [EXT] [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" > -----Original Message----- > From: dev On Behalf Of Matan Azrad > Sent: Monday, March 1, 2021 8:56 AM > To: Anoob Joseph ; dev@dpdk.org > Cc: Doherty, Declan ; Somalapuram Amaranath > ; Ruifeng Wang ; Ajit > Khaparde ; Zhang, Roy Fan > ; Griffin, John ; De Lar= a > Guarch, Pablo ; Michael Shamis > ; Nagadheeraj Rottela > ; Ankur Dwivedi ; > Gagandeep Singh ; Jay Zhou ; > Akhil Goyal ; Jerin Jacob Kollanukkaran > > Subject: Re: [dpdk-dev] [EXT] [PATCH] cryptodev: support multiple cipher = block > sizes >=20 >=20 >=20 > From: Anoob Joseph > > Hi Matan, > > > > With the current spec, AES-XTS operation offloading would mean > > application is expected to track data blocks and the corresponding > > tweak & cipher stealing, while the final crypto operation gets > > offloaded to PMD. This proposal aims at moving the entire AES-XTS > > operation (including tweak update) to PMD. Did I understand the proposa= l > right? >=20 > Yes, we want to define well what is the "data-unit" size from AES-XTS sta= ndard > per session (or operation), then, to allow to the PMD users to send multi= ple > data-units in one operation. > The initial tweak(for the first data-unit) will be set by the user in the= operation, > and according the standard(probably what you call "spec") the rest data-u= nits > tweak values should be assigned consecutively, so this part will be done= by the > PMD\device in multiple data-units case. >=20 > > > > If yes, I believe this is a good feature to be added. But I've few > > questions, > > > > 1. Who is responsible for cipher stealing? Do we expect PMD to pad the > > final data unit? > [Arek] - data units (including final) are of the same size, ciphertext stea= ling may concern only last AES block from every data unit if data unit size= is not multiple of AES block size. As there is ciphertext stealing no padding needed. =20 > Sure, this is the offload, no? to support what the algorithm defines. . >=20 > > 2. If we treat AES-XTS as an operation for just encrypting and > > decrypting a large blob of data, the current proposal would be good > > enough. But often, AES-XTS is used in disk encryption where selected > > pages are updated without requiring the entire disk to be decrypted (& > > encrypted after). Did you consider if we could extend the spec to > > support such a use case also? (Agreed that we could do page updates by > handling tweak etc from application as is being done now). >=20 > Sure, > For any amount of consecutive data-units, the user can do encrypt\decrypt= in > one operation: 1, 2, all the disk..... in one mbuf or chain of mbufs... > But the blob of data must be multiple of the session data-unit size param= eter > that I want to define now in the session API(\ transformation). >=20 > > 3. On top level, this requirement has similarities to rte_security. > > Did you consider that route? >=20 > No, but why do you care? The regular crypto API should support it too, it= is > basic... >=20 >=20 > > Thanks, > > Anoob >=20 > Thank you. >=20 > > > -----Original Message----- > > > From: Matan Azrad > > > Sent: Thursday, February 4, 2021 8:04 PM > > > To: dev@dpdk.org > > > Cc: akhil.goyal@nxp.com; Declan Doherty ; > > > Somalapuram Amaranath ; Ruifeng Wang > > > ; Ajit Khaparde ; > > > Anoob Joseph ; Fan Zhang > > > ; John Griffin ; > > > Pablo de Lara ; Michael Shamis > > > ; Nagadheeraj Rottela > > > ; Ankur Dwivedi ; > > > Gagandeep Singh ; Jay Zhou > > > > > > Subject: [EXT] [PATCH] cryptodev: support multiple cipher block > > > sizes > > > > > > External Email > > > > > > -------------------------------------------------------------------- > > > -- 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. > > > > > > 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. > > > > > > 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; > > > + /**< 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. > > > + * > > > + * - 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. > > > + */ > > > }; > > > > > > /** 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 > > > + > > > +/** > > > * 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