Message161898
| Author |
Jon.Oberheide |
| Recipients |
Jon.Oberheide |
| Date |
2012年05月29日.16:36:50 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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 |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年05月29日 16:36:52 | Jon.Oberheide | set | recipients:
+ Jon.Oberheide |
| 2012年05月29日 16:36:51 | Jon.Oberheide | set | messageid: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za> |
| 2012年05月29日 16:36:51 | Jon.Oberheide | link | issue14955 messages |
| 2012年05月29日 16:36:51 | Jon.Oberheide | create |
|