Hi all,

I was informed that the hmac.secure_compare() function added in 14532 is not time-independent when processing unicode values:

"The function as given is probably not timing independent if the attacker can provide unicode values. This is because (in CPython at least) all integer values in the range [-5, 256] inclusive are made singletons to avoid the performance hit of integer object creation, meaning that as long as (x ^ y) < 257, no integer object is created and the function appears constant time. When that assumption is violated, you get a timing delta that is actually fairly large compared to the delta for a single character compare."

One way to work around this issue is to perform strict 8-bit byte comparisons by converting any string type parameters to bytes via a utf-8 encode. The attached patch does this.

Regards,
Jon Oberheide

I'm not sure that encoding to UTF-8 is time indenpendant. You may try UTF-32-LE or unicode-internal?

Thanks for the feedback, haypo. I've updated the patch to use unicode-internal. As long as the encode() of the expected non-attacker-controlled digest is not dependent on the actual contents of the digest, we should be good.

The second patch looks fine.

With PEP 393 unicode objects can have several representations, which makes it unlikely that *really* constant-timing functions can be devised.

However, a C version could provide some guarantees, by raising an error if the passed unicode strings use a different representation from each other.

As a result of the discussions on #15061, I removed unicode comparison support altogether in f36af3766a20 (updating the warning on the hexdigest() method accordingly).

Are folks happy to close this issue on that basis? (I'll raise the question of a separate C implementation on the other issue)

Sounds good to me, Nick.

Nick has pushed a patch in rf36af3766a20 that disables the comparison of unicode strings. See #15061

Python 3.3 contains a secure and working implementation for bytes. unicode isn't supported unless both sides contains ASCII text only.