From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 169D6A04AC; Tue, 1 Sep 2020 10:18:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 624321515; Tue, 1 Sep 2020 10:18:58 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 60495137D for ; Tue, 1 Sep 2020 10:18:57 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id A941B580446; Tue, 1 Sep 2020 04:18:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 01 Sep 2020 04:18:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= jOYz/xo5xOGmOLyhVNz8tq8XCRMwNSE+LQ7S3XgSGhU=; b=FWIxADiWS2l3wOSr dbglZIj+nRAifN6qyTP/4ex7mnjPT2NCFk5J8DSIHCbvmzS2YUd260Tf3IBWpr5s vQrE4wA+lwD+QCuJ0LxFNQCWqgJAGG1fkHYN/ZGfQS0Rc543evRxMyBjjR0cs0zi Da/F4Vxf08EVlR/sA0dehjuKVW5ncat0ftSMk+MVCyJbkbFgvTjeOYMotwH9fEnL e7PcpqgwK22QaeC0Yyxcj3lyJpn6AlTajqlCzMW7CyErjLSUyNVdNK3NLA/yj8L2 MBNpH3Bx5b22N9fKdgHG5O32APdZGB9ASto7kWYn+7kR/F+LrlrxkBM3jr89X8rC p4ELZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=jOYz/xo5xOGmOLyhVNz8tq8XCRMwNSE+LQ7S3XgSG hU=; b=Pr6z1aFMInQCJ86W5Pb2VZ6UFdSPj6D7M5IR0CxpOqA96v/AHdwsE6lb8 SnueH6Za9iKMmx92vemOwfigWp16eFa0W/cCVVUnp7uQJkXjz7qd88hqdpBUO155 RaF5QQDl/FxlfBSzkIHqMsVktUfY0e8lRI3taa2sqU7hM+NtiXNQWcGS90Jf8o0X yjW5bU9O9rDKtj11lN9pLUO3Nkbc3JXo8O72wwNZIIMruwIHfbK5nwu48BylOoug KmadIb5IIUAyJiPm0sSvLJk+8RVRDwIaHonkKVHXvKA1rvid/KVH40Gekvfzkd20 tx7GikZ8GPyHpP6EMvgmD8xbqyOSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefjedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 42C05306005F; Tue, 1 Sep 2020 04:18:54 -0400 (EDT) From: Thomas Monjalon To: "Kusztal, ArkadiuszX" Cc: "dev@dpdk.org" , "akhil.goyal@nxp.com" , "anoobj@marvell.com" , "Doherty, Declan" , "Trahe, Fiona" , "asomalap@amd.com" , "rnagadheeraj@marvell.com" , "hemant.agrawal@nxp.com" , "De Lara Guarch, Pablo" , "Zhang, Roy Fan" Date: Tue, 01 Sep 2020 10:18:53 +0200 Message-ID: <10057334.se6I27zTtR@thomas> In-Reply-To: References: <20200805151514.1180-1-arkadiuszx.kusztal@intel.com> <4171449.91m3rO6bWt@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 31/08/2020 08:34, Kusztal, ArkadiuszX: > From: Thomas Monjalon > > 05/08/2020 17:15, Arek Kusztal: > > > This patch announces removal of RTE_CRYPTO_AUTH_AES_GMAC from > > > rte_crypto_auth_algorithm and addition of RTE_CRYPTO_AEAD_AES_GMAC to > > > rte_crypto_aead_algorithm. > > > AES-GMAC is variation of AES-GCM algorithm with the difference that it > > > does not perform encryption. As a matter of fact internally there is > > > no difference between GMAC and GCM except for the way how data is > > > passed. > > > Moving GMAC to AEAD can simplify way of implementing this alogrithm > > > for example in IPsec (RFC4543). > > > > > > Signed-off-by: Arek Kusztal > > > --- > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > +* cryptodev: ``RTE_CRYPTO_AUTH_AES_GMAC`` will no longer be included > > > +in > > > + ``enum rte_crypto_auth_algorithm``. It will be included in > > > + ``enum rte_crypto_aead_algorithm`` as ``RTE_CRYPTO_AEAD_AES_GMAC``. > > > > I wonder whether this move shows a problem in classification of the crypto > > algorithms. > > [Arek] - it is not particularly bad that GMAC is auth algorithm, it really depends on lib (openssl PMD internally uses conformant approach I have suggested in other mail). > But from what I currently see GMAC as AEAD is preferred way, I think this subject may be back in future. The strange thing is that AEAD is a kind of authentication, isn't it? I would see it as a subset of auth algos. > Anyway this proposal didn't meet its audience. > Because of the lack of ack (3 required), it cannot be accepted. Indeed. Why others did not approve? What is the consequence?