Hi Simon, On Wed, Sep 17, 2025 at 11:35:27AM +0200, Simon Josefsson wrote: > Collin Funk <[email protected]> writes: > > > I would rather not standardize a new function name for constant time > > comparisons. We already have consttime_memequal from NetBSD, as you > > mention, and timingsafe_bcmp/timingsafe_memcmp from OpenBSD, which > > preceded the NetBSD function, IIRC. > > Alejandro Colomar <[email protected]> writes: > > > I disagree with calling it secure_memeq(). Someone else will come up > > saying that while it's crypto-secure, it's not secure in the sense that > > it doesn't prevent buffer overflows if you pass a non-null-terminated > > buffer. > > > > If you want to add a function that works in constant-time, you should > > say that explicitly. For example: consttime_memeq(). > > Hah - I fully agree. How ironic that my criticisim was to use the word > "secure" in a too broad way, and I suggested in the same e-mail to use > the word "secure" in a too broad way for a narrow specialized function. > > >> I'm not sure a naive secure_memeq() will actually be > >> sufficient, maybe you want it to not even leak the length of the strings > >> passed to the function. That is impossible generally, > > > > For this, you only need to make sure you store all your sensitive data > > in buffers of the same size, and that you zero them before using. > > That way, you can call consttime_memeq(m1, m2, bufsize); all the time, > > regardless of the size of the meaningful data in m1 and m2. > > That isn't as simple as it may sound. Usually OS, libraries and > applications don't store variable-sized data in constant-size buffers.
Yup; it only works for certain data that you know to fit in a certain size. In shadow-utils, for example, we have a PASS_MAX macro that limits the maximum password size, and we reject anything above that. And we store all passwords in buffers of the same size. If you don't have an upper bound, it's impossible to do this. > So there will be some API that has to take variable-sized buffers and > convert them into constant-size buffers before using consttime_memeq() > is applicable. This leads to a timing problem in the code doing the > conversion. This problem is really deep and I don't see any simple > solution to it, except chosing protocols that aren't vulnerable to this > style of attack in the first place. Yup. It ain't easy. :) > > /Simon Cheers, Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
