Martin v. Löwis <mar...@v.loewis.de> added the comment: > The timing variations with standard comparison are relatively massive > and relatively easy to analyse (if the time taken goes up, you got > the previous digit correct).
If you have an application that is vulnerable to such an attack, you better reconsider your entire approach, rather than using a library function that says it will harden your approach (but may actually not). > Yes, the docs and name are currently completely unacceptable. But > scorched earth is not a good answer, because that just means people > will fall back to using "==" which is *even worse* from a security > point of view. It's not scorched earth. It's the standard procedure for adding features to the standard library. *At a minimum* there needs to be a use case, which has not been demonstrated yet (the OP of the original report thought he had a use case, but then agreed that he was wrong). Then, the use case should be fairly relevant for inclusion in the standard library. I wish there was an AES implementation in the library before we start worrying about stuff like this. Then, ideally, the new library function has been in wide use for some time. This was rushed, and it needs to be reverted. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15061> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
