Hi Simon, On Wed, Sep 17, 2025 at 10:14:22AM +0200, Simon Josefsson wrote: > Paul Eggert <[email protected]> writes: > > > I named the new module "stringeq"; it implements both streq and memeq > > in <string.h>. > > Looks great! > > > [2]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3617.txt > > Principles > - Enable secure programming > > I worry a bit about security implications here -- I understand your > intention here, but for crypto code memory/string equality checks have > security implications if implemented in non-constant time.
Security is a very broad concept. I certainly didn't refer to crypto here. > https://security.stackexchange.com/questions/160808/why-should-memcmp-not-be-used-to-compare-security-critical-data > > Could the description clarify that memeq and streq functions are NOT > intended to be constant-time depending on the input strings? Which I > presume is the property you desire here, since this seems more about > functionality and then performance is important. > > I wouldn't want anyone reading "secure programming" as meaning > constant-time operation. > > This opens up for adding proper secure_memeq() API which DO guarantee > constant-time though. What do you think about doing that? 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(). > NetBSD has consttime_memequal() for this, but I've not seen it generally > implemented. That certainly looks like a better name. I promise I hand't read this part of the email when I wrote the above. :-) > 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. > but for short > strings you can do better. Maybe it should guarantee leaking nothing > about string lengths for inputs < 255 bytes? I didn't look into the > NetBSD implementation if it cares about this. > > /Simon Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
