Antoine Pietri <antoine.piet...@gmail.com> added the comment:
On Wed, Oct 10, 2018 at 11:27 PM STINNER Victor <rep...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue34930> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
