question on NetBSD related statement

[spamwax]

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?

[krytarowski]

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]

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]

Simply no users of such interface so no need for it.

OpenBSD ships with timingsafe_memcmp() and all the uses could be replaced with timingsafe_bcmp().

[chmike]

@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]

@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]

NetBSD developers != OpenBSD developers; there are probably 0 shared developers between both OSes.

OpenBSD ones added timingsafe_memcmp(3) in order to easily replace memcmp(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]

@krytarowski Could you tell me precisely what text/comment I made that would unfairly blame anyone ?

[krytarowski]

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

Note that unlike memcmp(3), consttime_memequal() does not return a lexi-
cographic ordering on the data at b1 and b2; it tells only whether they
are equal.  NetBSD does not provide a consttime_memcmp() function,
because all known use cases that require `constant time' memory compari-
son also require only comparison for equality, not lexicographic order-
ing.

[spamwax]

returning -1 or 1 is not revealing anything on the compared data beside which one is bigger.

@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, 0 or just true or false?

[chmike]

@spamwax Yes. When only the equality needs to be tested, there are only two possible result. In this case true and false or 1 and 0 would 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]

@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]

"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]

@krytarowski The function consttime_memcmp I 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_memcmp in 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. memcmp from 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]

https://github.com/NetBSD/src/blob/trunk/common/lib/libc/string/consttime_memequal.c

Return value is mapped to 0 and 1.

[chmike]

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]

No, as there are no known use-cases and no potential users.

[chmike]

@krytarowski Does the modification of the readme answer your concern ?

[krytarowski]

It's ok now - thanks! If there will be ever a use-case, please let us know!