I think there's only one sensitive use of memcmp within nettle, and that's the tag comparison in ccm_decrypt_message. I've now written a private function memeql_sec to do that comparison in a more side-channel silent fashion.
static int memeql_sec (const void *a, const void *b, size_t n) { volatile const unsigned char *ap = (const unsigned char *) a; volatile const unsigned char *bp = (const unsigned char *) b; volatile unsigned char d; size_t i; for (d = i = 0; i < n; i++) d |= (ap[i] ^ bp[i]); return d == 0; }
The idea is to avoid leaking (via timing or memory access patterns) the location of the first difference. Information that a guess for a forged MAC tag matches some characters of the correct MAC can be used to attack the MAC key, in particular for MAC algorithms with linear structure such as gcm and poly1305 (which is why chacha-poly1305 uses a new poly1305 key for each message, and why one shouldn't use gcm with short authentication tags).
memeql_sec is a bit similar to http://nacl.cr.yp.to/verify.html.
Now, applications using nettle are likely doing a lot of similar comparisons on hash and hmac digests. So it would be good to make this function public. But then I'd need to decide on
1. A good name.
2. A suitable headerfile to declare it in. It would make some sense to group it together with memxor, but memxor.h isn't a good name for that header file.
Regards, /Niels