[issue34930] sha1module: Switch sha1 implementation to sha1dc/hardened sha1

[Antoine Pietri]

Antoine Pietri <antoine.pietri1 at gmail.com> added the comment:

On Wed, Oct 10, 2018 at 11:27 PM STINNER Victor <report at bugs.python.org> wrote:
> I dislike modifying a hash function to return its output but keep the same name. For name, "SHA1" must remain "SHA1". If you want a variant, it should have a different name, but I would expect that the existing sha1 function remains unchanged. How do you keep the compatibility between different programming languages and applications if one use SHA1 and the other uses "hardened SHA-1"?

Well, as I said we could almost consider both algorithms to be
"compatible", in that they only differ in an infinitesimally small
number of cases that were specifically *designed* to break SHA1. I
agree it's not ideal to just replace the function directly, and that's
why I suggested 4 possible alternatives. But you have to understand
that the decision is not as simple as just "it doesn't give the same
outputs so it should have a different name", because it *does* give
the same outputs in *all of the cases that weren't designed to break
it*, and the tradeoff for not making that the default is that most
people who don't care about seeing the collisions happen will keep
using a broken implementation for no reason.

I'm not saying I disagree with you here, I'm just making sure you're
aware of the tradeoff. If we make it the default, it's a *very slight*
break of backwards compatibility, but it will be a positive change for
99.99% of users. The only affected people will be the ones that were
writing scripts to check whether collisions did exist in the old
algorithm, and if we change the name of the "classic sha1" they could
trivially change it themselves.

That said, if you'd rather have another name for it, it also works for
me, it's better than having nothing.

> One alternative is to stop using sha1 :-D

Totally agree with you here, but it's not always an option, so I'd
argue we should do our best to mitigate the problem.

> Do you have examples?

I already gave the Git example:

https://github.com/git/git/commit/28dc98e343ca4eb370a29ceec4c19beac9b5c01e#diff-a44b837d82653a78649b57443ba99460

Fossil also migrated to it:

https://www.fossil-scm.org/xfer/doc/trunk/www/hashpolicy.wiki

The truth is, most of the other Merkle Tree implementations (like
Bitcoin) were using a different hash in the first place, and that
seems to be the main application where you have to keep backward
compatibility with your hashes. So the fact that two of the main SHA-1
Merkle tree implementations moved to Hardened SHA-1 is huge, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34930>
_______________________________________