From b1ff8daeb521d1645bc35ffd7191599b7169c2bb Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 13 Dec 2012 17:34:05 -0500 Subject: Nuke uses of memcmp outside of unit tests We want to be saying fast_mem{cmp,eq,neq} when we're doing a comparison that's allowed to exit early, or tor_mem{cmp,eq,neq} when we need a data-invariant timing. Direct use of memcmp tends to imply that we haven't thought about the issue. --- src/common/aes.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'src/common/aes.c') diff --git a/src/common/aes.c b/src/common/aes.c index 2d64b85944..d8865d7116 100644 --- a/src/common/aes.c +++ b/src/common/aes.c @@ -41,6 +41,7 @@ #include "aes.h" #include "util.h" #include "torlog.h" +#include "di_ops.h" #ifdef ANDROID /* Android's OpenSSL seems to have removed all of its Engine support. */ @@ -257,7 +258,7 @@ evaluate_ctr_for_aes(void) for (i=0; i<16; ++i) AES_ctr128_encrypt(&zero[i], &output[i], 1, &key, ivec, ivec_tmp, &pos); - if (memcmp(output, encrypt_zero, 16)) { + if (fast_memneq(output, encrypt_zero, 16)) { /* Counter mode is buggy */ log_notice(LD_CRYPTO, "This OpenSSL has a buggy version of counter mode; " "not using it."); -- cgit v1.2.3-54-g00ecf