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