[issue15061] hmac.secure_compare() leaks information about length of strings
Antoine Pitrou
report at bugs.python.org
Fri Jun 15 14:21:39 CEST 2012
Antoine Pitrou <pitrou at free.fr> added the comment:
> 2. Providing a C implementation via the operator module (given the
> restriction to bytes values, and the assumption of caching for all
> relevant integers, would a C reimplementation really be buying us much
> additional security?)
I like the fact that a C implementation can be audited much more easily.
Who knows what kind of effects the Python implementation can trigger, if
some optimizations get added in the future.
> As far as restoring unicode support (even in a C implementation) goes,
> I actually don't like the idea. For the general unicode case, as
> suggested in the updated documentation for hexdigest(), I believe the
> better approach is to try to stay in the bytes domain as much as
> possible, and avoid having a Unicode->bytes conversion for the
> expected value anywhere in the comparison timing path.
The point of supporting unicode would precisely be to avoid a
unicode->bytes conversion when unicode strings are received.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15061>
_______________________________________
More information about the Python-bugs-list
mailing list