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 BA17B48868 for ; Tue, 30 Sep 2025 01:54:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B46B540661; Tue, 30 Sep 2025 01:54:17 +0200 (CEST) Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by mails.dpdk.org (Postfix) with ESMTP id B2D75402A2 for ; Tue, 30 Sep 2025 01:54:14 +0200 (CEST) Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-796d68804a0so59944496d6.3 for ; Mon, 29 Sep 2025 16:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1759190054; x=1759794854; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=8yjbk0nw9bPJVfxqsjidEJuO3KYNBnUETvoxWrwWPKU=; b=ZyhXjpJ8Rn6Oehtz2VdcARq4wzh99bJS3EU/PhTQ+bP/GWamg91BSfBQ+XYqaQ0OZC nsli7r8PISZowSvpquhY+MkYRW/Y6ZJeRWbmozAmEhZ+N36ETkFHk2gp0lBu/bP+LtWG I1GBV5tQR+02+nAG8Wx1dzJD+KrnCZvops5yHDQ4cqtHGyJrm6NBTU/agQjPHhRsA8Ox EUdnVMkli3sV31PWO4RK+21tJxsvhWa6CAkoiNbU133FJWkuDZIOL7akYT9QGpxPZBx3 oYYs8Bm7js5brDhbS5b/JgdwRYz4Kq48TgQT6uic94fFMbFwTyv50UWbTWwwH4MXirKG e9LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759190054; x=1759794854; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8yjbk0nw9bPJVfxqsjidEJuO3KYNBnUETvoxWrwWPKU=; b=GZ8bV8FvcKcEqKH3a8PQc+EjJ4FI0F6dUlmv82+o9ntDTYb+8GRS6oWIMeHRWrsx5D 9Lshwqlsvy933wjtmdf1+hgJD8Jwk9a1KWxQudgU+r37CshP09ElRccYLO8lc2ZWXM7v DMANhZebrkUNZW9sNj3bM/H44cuf6dUYBhRLaM1S2hPlCx6+XSlrpR0cqOzhtKL1C7fl j3cUPrYxogEQM0nutWFTTnZ56WupoSQw0rK/UyNNO+6qcmXOw/oi7pC+4Mag+SB2pUQ0 xuMWJTgpSGPgMwltbSj+x/0pI+iThAZ0WmMqQr3JsbuXE0zu2ICJuB3WVWEOqtlLl6j4 ueRw== X-Forwarded-Encrypted: i=1; AJvYcCVVz3Eo4JZSeXXz6sV0eoK1JHqFTwj/SXEH8yWMN8NzOn8UuDnPFQiGpTrC+mZoeFkQ5kaPcOY=@dpdk.org X-Gm-Message-State: AOJu0YzxxHw7b87AE2xpBb6q9ry4wk3rvz1x9x/7e6TIjl3MLBrhyODl srRMIj61n/t4JfgiY7wpMawfFaKpD8SzwtrObf8Tk08GDz8SJ1AVfKd2K6U91YTgHY4= X-Gm-Gg: ASbGnctCif2y721YDejCDQCoeHEtyTOWa1IyQ5aNm+pxnStBjq2JyGTLxg/MB0Eg+Qt GbFb+KeJQLLSZVPGvP8BMZ7hsGl+lb6AODjV+GyS/A7pF1kw4L0e1fG9vXQLGo/SNVysfyO4kQq pP3FY9/Y2XYnMJzxBw8NqvLp+ag65rmON44JntuCG4HQlowCzn2FRG6deQd2+E4IHW0fG9J1Bet LsJrjJqpVsJyGJpwLE4jvtVCKwcmuPQmf3LvzaqjkAMo3QOyGd6r8FVC2iiLYunGb2sKMTVMeeM fB1tTWkz8YttwY2k6VedYZvaN3nAVpliAaiBMEQDKvlUUS1RCqouF/uEEq0ykDcIGwZzaeuLrSq l5tnvwVoXTB/KTA63x2BwA2d/AuD7K/4G1pHgvXIQeiYVVcLhjU5iRelXTwjHyY9qkB/vwSvhoo KJQDF9lW1g7A== X-Google-Smtp-Source: AGHT+IHj5UMiuMRuwevDGhyDaKwiVOm3hb1bxDrqBbK9Q0d+3IP1d6J3bjYiIqo3ygLtSCP2UzupMw== X-Received: by 2002:a05:6214:519c:b0:782:3e4c:9ea0 with SMTP id 6a1803df08f44-7fc417af022mr254880646d6.59.1759190053959; Mon, 29 Sep 2025 16:54:13 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4db0b9458e1sm83823621cf.15.2025.09.29.16.54.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Sep 2025 16:54:13 -0700 (PDT) Date: Mon, 29 Sep 2025 16:54:08 -0700 From: Stephen Hemminger To: Kai Ji Cc: dev@dpdk.org, gakhil@marvell.com, konstantin.ananyev@huawei.com, bruce.richardson@intel.com, thomas@monjalon.net, mb@smartsharesystems.com, stable@dpdk.org Subject: Re: [dpdk-dev v4 2/2] crypto/ipsec-mb: use constant-time memory comparison Message-ID: <20250929165408.1c9d9d2a@hermes.local> In-Reply-To: <20250929145049.153078-2-kai.ji@intel.com> References: <20250926160209.56496-1-kai.ji@intel.com> <20250929145049.153078-1-kai.ji@intel.com> <20250929145049.153078-2-kai.ji@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Mon, 29 Sep 2025 14:50:49 +0000 Kai Ji wrote: > Replace memcmp() with rte_memneq_consttime() in cryptographic > authentication verification operations across iipsec-mb drivers. > > Note: OpenSSL crypto driver already uses CRYPTO_memcmp() which > provides equivalent timing attack resistance and is left unchanged. > > Note: scheduler driver memcmp stays unchanged as its not secret data > comparison and actually faster with no timing attack risk. > > Bugzilla ID: 1773 > Cc: stable@dpdk.org > > [0] https://bugs.dpdk.org/show_bug.cgi?id=1773 > > Signed-off-by: Kai Ji > --- Thanks for doing this. A couple other notes from my searching around. The function memeq_consttime is in NetBSD (not FreeBSD) sorry if I got confused. OpenBSD has timingsafe_memcmp() and timingsafe_bcmp(). Also this on LWN: > You would use a constant-time version of memcmp. OpenBSD added timingsafe_bcmp in 2009, and then timingsafe_memcmp a few years later. (https://man.openbsd.org/timingsafe_memcmp.3) NetBSD has consttime_memequal. (https://man.netbsd.org/consttime_memequal.3) Apple and FreeBSD adopted the OpenBSD routines. > I don't think either glibc or musl libc have adopted a similar interface. So on Linux or for portable software you'd probably want to use CRYPTO_memcmp from OpenSSL. > > You should of course be hashing the passwords with salts, and only comparing those hashes. In which case using a constant-time compare isn't that important as the attacker can't work backward from the short-circuiting compare to decipher the plaintext input. The hashing itself should be constant-time, assuming modern digests like SHA-256 or SHA-3, though it's possible the *length* of the input password would leak. But there are a gazillion ways for the length to leak, and when it comes to password-based authentication schemes that's the least of your worries. > > >