[dpdk-dev v4 2/2] crypto/ipsec-mb: use constant-time memory comparison

[Stephen Hemminger]

On Mon, 29 Sep 2025 14:50:49 +0000
Kai Ji <kai.ji at intel.com> 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 at dpdk.org
> 
> [0] https://bugs.dpdk.org/show_bug.cgi?id=1773
> 
> Signed-off-by: Kai Ji <kai.ji at intel.com>
> ---

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.
> 
> 
>