[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