[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-10-06 Thread Christian Heimes
Christian Heimes added the comment: Python 3.3 contains a secure and working implementation for bytes. unicode isn't supported unless both sides contains ASCII text only. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed _

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-06-19 Thread Christian Heimes
Christian Heimes added the comment: Nick has pushed a patch in rf36af3766a20 that disables the comparison of unicode strings. See #15061 -- dependencies: +hmac.secure_compare() leaks information about length of strings ___ Python tracker

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-06-15 Thread Jon Oberheide
Jon Oberheide added the comment: Sounds good to me, Nick. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-06-15 Thread Nick Coghlan
Nick Coghlan added the comment: 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

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-06-14 Thread Hynek Schlawack
Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-06-14 Thread Antoine Pitrou
Antoine Pitrou added the comment: 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 differen

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-06-13 Thread Christian Heimes
Christian Heimes added the comment: The second patch looks fine. -- nosy: +christian.heimes ___ Python tracker ___ ___ Python-bugs-li

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-06-02 Thread Jon Oberheide
Jon Oberheide added the comment: 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. -- Added file: http://bugs.

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-05-30 Thread STINNER Victor
STINNER Victor added the comment: I'm not sure that encoding to UTF-8 is time indenpendant. You may try UTF-32-LE or unicode-internal? -- nosy: +haypo ___ Python tracker ___ __

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

2012-05-29 Thread Jon Oberheide
New submission from Jon Oberheide : 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 C