Joachim Strömbergson joachim@secworks.se writes:
Yes, and a good function to add. One could think/hope that the OS provided side channel silent memory functions.
Plain memcmp should be optimized for speed, I guess.
AFAIK (browsing the docs) there aren't any specific functions for comparing digests. Instead the user has to implement thing themselves.
I also did a search for memcmp, and it's used in very few places inside nettle (there are also bignum-comparisons, which may have similar issues).
But applications are expected to compare digests, produced by some of the mac or aead constructions, and they'd typically use plain memcmp. So a side-channel silent variant should definitely be documented and recom,ended for users.
I'm now thinking aloud, but maybe it would make sense to also change the various digest functions to return the pointer to the digest? So one could do, e.g.,
if (mem_equal (hmac_sha256_digest(...), expected, SHA1_DIGEST_SIZE)) ...;
or even
#define DIGEST_EQUAL(ctx, f, size, buf, expected) \ mem_equal(f(ctx, size, buf), expected, size)
(I'm not saying that macro is a good idea, but returning the pointer makes such things simpler).
Or one could add a corresponding _verify function for each _digest function, which takes the expected digest as input. Not sure that's a good idea. That would be a pretty large number of functions, but if it makes applications simpler, it could be worth the effort.
uint8_t compare_digests(uint8_t *digest0, uint8_t *digest1, uint8_t *DIGEST_SIZE);
That looks similar to the mem_equal I sketched, except that the third argument looks strange. Was that intentional?
Regards, /Niels