>> that is only the first step in the development of a successful attack. Finding a collision of any type is hard; finding one that is still working code, that

>> that is only the first step in the development of a successful attack. Finding a collision of any type is hard; finding one that is still working code, that has the functionality the attacker is after, and that looks reasonable to both humans and compilers is quite a bit harder — if it is possible at all. > I mean, if you have any sort of binary files in your repo, that's pretty doubtful. > The way you mostly do this, is the colliding part is a short binary blob which is embedded, and then the file has code outside the colliding part that does different things depending on the value of the blob. > Yeah, getting that past human review with a source code file is going to be tricky. Otoh if you have any sort of binary assets in your git, (this might even include images depending on the attack goals, e.g. goatse attack) this seems a lot more plausible My view is that if you find yourself rationalizing away potential cryptographic issues with "I bet this will be hard to successfully attack in practice", you're probably better off just fixing the problem if you can. Once you've moved from just relying on cryptographic security to non-cryptographic factors like human code reviews or constrained input formats, you've made it significantly more complicated to evaluate the security of your system and significantly increased the risk that an attacker comes up with an approach you haven't considered. It's very tempting to conclude that a cryptographic attack isn't really an issue for your system and you don't have to change anything, but that conclusion is almost certainly not based on a real understanding of the risk you're accepting. Just using SHA-256 or something similar is almost always a better answer than coming up with some more complicated reason to keep using SHA-1.