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. 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. /Simon
signature.asc
Description: PGP signature
