Joachim Strömbergson <[email protected]> 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
--
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
