Message163385
| Author |
serhiy.storchaka |
| Recipients |
Jon.Oberheide, alex, christian.heimes, fijall, georg.brandl, hynek, loewis, ncoghlan, petri.lehtinen, pitrou, python-dev, serhiy.storchaka |
| Date |
2012年06月22日.06:08:51 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1340345342.2703.43.camel@raxxla> |
| In-reply-to |
<1340314923.3400.0.camel@localhost.localdomain> |
| Content |
> > > We could handle all bytes-compatible objects, using the buffer API.
> > It is timing unsafe.
> How so?
I checked myself, and I see that most likely I was wrong. At least for
bytes and bytearrays it is timing safe.
> I don't think that's the right answer, because people will instead e.g.
> encode('utf-8'), and suddently the encodingly will not be timing-safe.
And what of that? It is outside of the timingsafe_eq function. People
can also do other timing unsafe operations with the secret key (for
example reading it from file or from DB) or not to use timingsafe_eq at
all. The secret key should be pre-encoded.
The error will be if code works for developer from ASCII word, and then
on the other side of ocean it will no longer work with non-ASCII
strings. You are expected to be familiar with such issues. In any case,
the obvious (and simplest, and fastest) way to check that a string is
ASCII-only is try to encoded it to ASCII. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年06月22日 06:08:53 | serhiy.storchaka | set | recipients:
+ serhiy.storchaka, loewis, georg.brandl, ncoghlan, pitrou, christian.heimes, alex, fijall, python-dev, petri.lehtinen, hynek, Jon.Oberheide |
| 2012年06月22日 06:08:52 | serhiy.storchaka | link | issue15061 messages |
| 2012年06月22日 06:08:51 | serhiy.storchaka | create |
|