Repository navigation
question on NetBSD related statement #2
Description
We compare our code execution time with the function consttime_memcmp() provided in NetBSD. Unfortunately this function doesn't return -1 or 1 and thus reveal something of the compared memory zone.
Isn't not returning -1 or 1 less revealing? When you return -1 or 1, we give away inequality and which one is smaller, vs just returning 0 vs 1 to say they are not equal?
What am I missing here?
Activity
krytarowski commentedon Feb 8, 2018
The NetBSD developers failed to find any use-case when we require memcmp(3) with consttime property. This is why we return only whether a string is equal or not.
spamwax commentedon Feb 9, 2018
that makes sense to me, but I still don't understand the above statement in which it is implied returning only if strings are equal is somehow more revealing than telling which one is smaller/larger!
krytarowski commentedon Feb 9, 2018
Simply no users of such interface so no need for it.
OpenBSD ships with
timingsafe_memcmp()and all the uses could be replaced withtimingsafe_bcmp().chmike commentedon Feb 9, 2018
@spamwax returning -1 or 1 is not revealing anything on the compared data beside which one is bigger. The other function is returning the arithmetic difference of the two first different bytes. The sign tells us which one is bigger, but it also reveals the byte difference. My function does not reveal anything about the compared bytes beside which one is bigger when byte compared.
Now this difference may seam negligible. That is up to you to decide according to your use of the result, the compiler and the processor.
chmike commentedon Feb 9, 2018
@krytarowski I don't think that what the OpenBSD developers thinks is of any relevance here. You see, Intel's engineers also didn't see a problem with what came out as the Meltdown and Spectre bugs. So this is really not an argument. The usefulness depends on the use case, and I don't see how you can assert there will never be a use case for such function.
My goal was to derive an algorithm with the desired properties and to publish it so that anyone who want to use it can use it freely. My goal is achieved. I don't understand why you disparage this open source contribution.
krytarowski commentedon Feb 9, 2018
NetBSD developers != OpenBSD developers; there are probably 0 shared developers between both OSes.
OpenBSD ones added
timingsafe_memcmp(3)in order to easily replacememcmp(3).Blaming the NetBSD version isn't fair unless you will show us a use-case. We keep homegrown implementations of timing safe
memcmp(3)too, but not in the main tree.chmike commentedon Feb 9, 2018
@krytarowski Could you tell me precisely what text/comment I made that would unfairly blame anyone ?
krytarowski commentedon Feb 9, 2018
The first sentence in this thread. "Unfortunately" -> deliberately; and lack of information why we skip it. It's documented in a man-page.
http://netbsd.gw.com/cgi-bin/man-cgi?consttime_memequal++NetBSD-current
spamwax commentedon Feb 10, 2018
@chmike
I see, thanks.
I was confused because I though the other function is
men_equal!!! which is not hence the source of confusion.But in general, given a use case where only equal-ness is needed, would you say it is better to return
-1, 1, 0or just true or false?chmike commentedon Feb 11, 2018
@spamwax Yes. When only the equality needs to be tested, there are only two possible result. In this case
trueandfalseor1and0would be fine.Don't use my algorithm to simply test for equality. Use the canonical and simpler algorithm which are provided by good crypto libs.
chmike commentedon Feb 11, 2018
@krytarowski I acknowledged my unawareness of the reason NetBSD had no constant time memcmp function. Would you like me to change something in the readme or source code comments to fix any unfair blaming ? Feel free to make any suggestion. I'll fix it ASAP.
krytarowski commentedon Feb 11, 2018
"Unfortunately this function doesn't return -1 or 1 and thus reveal something of the compared memory zone." -> I would change to something close to: "By design this function doesn't return a lexicographic ordering on the compared data, because all known (to NetBSD developers) use cases that require timing safe property also require only comparison for equality".
chmike commentedon Feb 12, 2018
@krytarowski The function
consttime_memcmpI attribute to NetBSD and reproduce on my web page returns the arithmetic difference of the first two different bytes, or 0 if none. It thus doesn't match the manual page you referenced above.Unfortunately, I didn't provide a reference of the web page where I collected that function. My bad.
Would it mean that the
consttime_memcmpin NetBSD current only returns 0 or 1 ?Could you please help me clarify this ? Do you have a pointer to the current source of this function ?
A function testing for equality should be called
memeq.memcmpfrom libC has a different semantic. It performs a lexicographical comparison of a byte sequence. This is confusing.Whether leaking information on the byte difference is unfortunate, is another issue.
krytarowski commentedon Feb 12, 2018
https://github.com/NetBSD/src/blob/trunk/common/lib/libc/string/consttime_memequal.c
Return value is mapped to 0 and 1.
chmike commentedon Feb 14, 2018
That function is memequal, not memcmp. I apparently got the consttime_memcmp from here: ftp://ftp.icm.edu.pl/pub/NetBSD/misc/apb/consttime_memcmp.c
Isn't this part of NetBSD ?
krytarowski commentedon Feb 14, 2018
No, as there are no known use-cases and no potential users.
remove invalid link of consttime_memcmp to NetBSD
chmike commentedon Feb 15, 2018
@krytarowski Does the modification of the readme answer your concern ?
krytarowski commentedon Feb 15, 2018
It's ok now - thanks! If there will be ever a use-case, please let us know!