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 D6FE545701; Wed, 31 Jul 2024 14:51:30 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C597B40A87; Wed, 31 Jul 2024 14:51:30 +0200 (CEST) Received: from fhigh4-smtp.messagingengine.com (fhigh4-smtp.messagingengine.com [103.168.172.155]) by mails.dpdk.org (Postfix) with ESMTP id 1D49D4065D for ; Wed, 31 Jul 2024 14:51:29 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 88B911146D08; Wed, 31 Jul 2024 08:51:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 31 Jul 2024 08:51:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1722430288; x=1722516688; bh=X2mpgDYsGSvvlLhlC82IwjSXh7WfBcKMJ1SrbZZFc14=; b= dNvmGf9o77Nlgw0n/WA9CA3aiwA+Q0gwW9ofH9JVvpaJAMXGgpAEWFsQMld3E3dZ qrFMw1XVziqMC4eRbYigHIyxHI6rz8XUqVKp9LgWFMZn31+Zj7vBhuVQUtaiFK7g vaEVWTZr2ndcI1qnT/z6rt1g18km+Dxd8O2vhPDvMW4H4w42xOcduoTxfmDxyV90 Wf8GuAGS/bU/oK0HewV2QIPHFaLYoMg3fMAdqK4Lgd7RqW2kMJqhGYx8FUGhjlWh OXv9atQX6KFTwsGHfmiReLbH356hOwiWzOatB3TBefJcMvHYdxZY9oENGDLj6o2s fbhQS+R/TKjyehrmwROr5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1722430288; x= 1722516688; bh=X2mpgDYsGSvvlLhlC82IwjSXh7WfBcKMJ1SrbZZFc14=; b=a xG7825LiFXkTybXX2va8BWV08Go5tBIMK+ADp+zIF1cupoRWkosfZhGRdJGP5hnh ehhZWIC+zehK0MpBuueQfezShi7hia1Js87qh+voez+jqXZiiuJCxEs4mDziiFck GNV3Bukntk4drQIgL/cFY3HxXU52lldqV4hbw1lJCDXhvRnDKGvio14kky/GyUzi Y2/clKumu0rJS788MCQIuE+2SsZDDRMoUBC1+YFPD9LlgdwPiJY/SDAvEWgbrIFh G2/6zvzgwwkRIXhPmhPfe2a3iuxnhCx2iT2S7Ud1NCcWxeC+d6ppzUub2uniqXn2 MAmtO3/TFSx138yGmO4dw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrjeeigdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepjeduveehieevuddutdevfffgtdegkeeuveejffejgedtgeegkefg vdeugfefkeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthdpnhgspghrtghpthhtoheptd X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 31 Jul 2024 08:51:24 -0400 (EDT) From: Thomas Monjalon To: Gowrishankar Muthukrishnan Cc: "Kusztal, ArkadiuszX" , "dev@dpdk.org" , Anoob Joseph , "Richardson, Bruce" , "ciara.power@intel.com" , Jerin Jacob , "fanzhang.oss@gmail.com" , "Ji, Kai" , "jack.bond-preston@foss.arm.com" , "Marchand, David" , "hemant.agrawal@nxp.com" , "De Lara Guarch, Pablo" , "Trahe, Fiona" , "Doherty, Declan" , "matan@nvidia.com" , "ruifeng.wang@arm.com" , "Gujjar, Abhinandan S" , "maxime.coquelin@redhat.com" , "chenbox@nvidia.com" , "sunilprakashrao.uttarwar@amd.com" , "andrew.boyer@amd.com" , "ajit.khaparde@broadcom.com" , "raveendra.padasalagi@broadcom.com" , "vikas.gupta@broadcom.com" , "zhangfei.gao@linaro.org" , "g.singh@nxp.com" , "jianjay.zhou@huawei.com" , "Daly, Lee" Subject: Re: [PATCH] doc: announce cryptodev changes to offload RSA in VirtIO Date: Wed, 31 Jul 2024 14:51:23 +0200 Message-ID: <4036290.2iPT33SAM4@thomas> In-Reply-To: References: <20240722145551.1159-1-gmuthukrishn@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" 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 30/07/2024 16:39, Gowrishankar Muthukrishnan: > Hi, > We need to fix padding info in DPDK as per VirtIO specification in order to support RSA in virtio devices. VirtIO-crypto specification and DPDK specification differs in the way padding is handled. > With current DPDK & virtio specification, it is impossible to support RSA in virtio-crypto. If you think DPDK spec should not be modified, we will try to amend the virtIO spec to match DPDK, but since we do not know if the virtIO community would accept, can we merge the deprecation notice? There is a long list of Cc but I see no support outside of Marvell. > >>> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from > >>> + rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct, > >>> + breaking ABI. The new location is recommended to comply with > >>> + virtio-crypto specification. Applications and drivers using > >>> + this struct will be updated. > >>> + > > > >> The problem here, I see is that there is one private key but multiple combinations of padding. > >> Therefore, for every padding variation, we need to copy the same private key anew, duplicating it in memory. > >> The only reason for me to keep a session-like struct in asymmetric crypto was exactly this. > > > > Each padding scheme in RSA has its own pros and cons (in terms of implementations as well). > > When we share the same private key for Sign (and its public key in case of Encryption) between > > multiple crypto ops (varying by padding schemes among cops), a vulnerable attack against one scheme > > could potentially open door to used private key in the session and hence take advantage > > on other crypto operations. > > > > I think, this could be one reason for why VirtIO spec mandates padding info as session parameter. > > Hence, more than duplicating in memory, private and public keys are secured and in catastrophe, > > only that session could be destroyed. > > > >>> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key > >>> + in either exponent or quintuple format is changed from union to > >>> +struct > >>> + data type. This change is to support ASN.1 syntax (RFC 3447 Appendix A.1.2). > >>> + This change will not break existing applications. > > > > > > This one I agree. RFC 8017 obsoletes RFC 3447.