This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Jon.Oberheide, alex, christian.heimes, fijall, georg.brandl, hynek, loewis, ncoghlan, petri.lehtinen, pitrou, python-dev, serhiy.storchaka
Date 2012-06-23.15:08:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340464138.35.0.479623648128.issue15061@psf.upfronthosting.co.za>
In-reply-to
Content
This is why I wanted to close the issue with the pure Python implementation, and punt on the question of a C accelerator for the moment.

compare_digest is effectively the same as what all the Python web servers and frameworks do now for signature checking. Yes, it's more vulnerable to timing attacks than a C implementation, but it's going to to take a sophisticated attacker to attack that through the noise of network jitter. It's sufficiently hardened that's it's unlikely to be the weakest link in the security chain.

For 3.4, I hope to see a discussion open up regarding the idea of something like a "securitytools" module that aims to provide some basic primitives for operations where Python's standard assumptions (such as flexibility and short circuiting behaviour) are a bad fit for security reasons. That would include exposing a C level full_compare option, as well as the core pbkdf2 algorithm.
History
Date User Action Args
2012-06-23 15:08:58ncoghlansetrecipients: + ncoghlan, loewis, georg.brandl, pitrou, christian.heimes, alex, fijall, python-dev, petri.lehtinen, hynek, serhiy.storchaka, Jon.Oberheide
2012-06-23 15:08:58ncoghlansetmessageid: <1340464138.35.0.479623648128.issue15061@psf.upfronthosting.co.za>
2012-06-23 15:08:57ncoghlanlinkissue15061 messages
2012-06-23 15:08:57ncoghlancreate