On Sun, 23 Jun 2013, Taylor R Campbell wrote:
From: christos%astron.com@localhost (Christos Zoulas) We should not be creating new interfaces based on obsolete ones. I'd rather we have consttime_memcmp() and explicit_memset().I don't care if we rename them to consttime_memeq and explicit_memzero instead, but these are absolutely the operations that real crypto applications need. consttime_memcmp and explicit_memset are not, and are needlessly complicated.
I see the point about avoiding names that resemble the deprecated functions bcmp() and bzero(). I also agree with the point that the memcmp() interface is not what is wanted here. I don't care so much about the difference between the bzero() and memset() interfaces.
Because the implementation of consttime_memcmp() would be complex, I'd object to adding it unless there's a caller that needs the three-state return value.
I think that the names explicit_memzero() and consttime_memeq() are fine, but I'd expect consttime_memeq() have the opposite polarity from consttime_bcmp(), because it should be answering the question "are they equal?" (1 for true), not "in what order do they compare for sorting?" (0 for equal).
By the way, I have an implementation of consttime_memcmp() at <ftp://ftp.netbsd.org/pub/NetBSD/misc/apb/consttime_memcmp.c>.
--apb (Alan Barrett)