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
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
