people don't really care, because current collision methods are mitigated.
Git does not actually use "sha1", despite what all the docs say, it uses "sha1dc", which is just like sha1 except for inputs which can cause collisions, in which case it either fails with clear error message or returns completely different value.
In this case "hash" will be the same as SHA1(input) in all cases, except those where the input is detected to be malicious (as in the SHAttered attack)
I don't see how this can be more than a fundamentally forward-incompatible sticking plaster over the problem. The problem isn't merely that "detecting maliciousness" seems fraught in itself (how does one infer intent reliably?) -- it's that today's SHA1DC() implementation can only detect and optionally correct today's known attacks, so each new attack necessitates a new, incompatible version of SHA1DC().
Each new _unrelated_ SHA1 attack will need an update in SHA1DC. But it has to be truly unrelated, as the collision detection method is fairly robust. I recommend reading the original "Counter-cryptanalysis" paper [0] for details on how attacks work and how they can be mitigated (there is certain internal state in SHA1 that is used in all known attacks). BTW, this paper has an interesting anecdote: apparently Flame malware had exploited MD5 collisions using novel unpublished attack method... and yet it was detected by collision detector (section 3.2). Another example is that SHA-mbles attack, published 3 years after "Counter-cryptanalysis", was detected as well, with no required code changes.
No, there is nothing "fundamentally incompatible" in the new SHA1DC method. After all, git came out in 2005, 11 years before SHA1 attacks were known, so it used regular SHA1. The collision detector was added in 2017 and nothing broke, because false positive chance is 2^-90 [1].
I have not heard of any new SHA1 collision results, but if they are based on no-difference differential paths, git has nothing to worry about. And if they are not, it may be possible to extend DC detector to seamlessly detect and prevent those attacks, and then only upgrade git clients, keeping backward and forward compatibility for data.
Of course there is always a chance that someone will come out with all-new SHA1 preimage attack that cannot be detected without high rate of false positive, so it's prudent to switch git to sha256. There is a lot of work being done: git's sha256 mode went out of beta in 2.42 (2023), but neither github nor gitlab support it.
But since the current state of git's sha is that there is nothing broken, and git git commit hash _is_ "enough to know you are distributing/executing the legitimate code, as opposed to a malicious doppelganger", there is no real pressure.
The problem isn't merely that "detecting maliciousness" seems fraught in itself (how does one infer intent reliably?)
Its not detecting "intent" it is detecting that the hash is one vulnerable to the attack, which is extremely unlikely to happen by accident, so if you see it you can assume malice.
It might be a band-aid, and sha256 is certainly a much better solution, but its more robust than it sounds at first glance (since it sounds crazy at first glance)
Sure it's plaster, but plaster can last a good while. Sufficiently new attacks don't come around all that often, and every hash has a risk of new attacks showing up.
Comments
people don't really care, because current collision methods are mitigated.
Git does not actually use "sha1", despite what all the docs say, it uses "sha1dc", which is just like sha1 except for inputs which can cause collisions, in which case it either fails with clear error message or returns completely different value.
https://news.ycombinator.com/item?id=17825441
so don't worry, git hashes _are_ enough to know you are distributing/executing the legitimate code.
(not to mention you need a preimage attack to replace known commit, and this is not yet possible with sha1)
From your link:
I don't see how this can be more than a fundamentally forward-incompatible sticking plaster over the problem. The problem isn't merely that "detecting maliciousness" seems fraught in itself (how does one infer intent reliably?) -- it's that today's SHA1DC() implementation can only detect and optionally correct today's known attacks, so each new attack necessitates a new, incompatible version of SHA1DC().
Each new _unrelated_ SHA1 attack will need an update in SHA1DC. But it has to be truly unrelated, as the collision detection method is fairly robust. I recommend reading the original "Counter-cryptanalysis" paper [0] for details on how attacks work and how they can be mitigated (there is certain internal state in SHA1 that is used in all known attacks). BTW, this paper has an interesting anecdote: apparently Flame malware had exploited MD5 collisions using novel unpublished attack method... and yet it was detected by collision detector (section 3.2). Another example is that SHA-mbles attack, published 3 years after "Counter-cryptanalysis", was detected as well, with no required code changes.
No, there is nothing "fundamentally incompatible" in the new SHA1DC method. After all, git came out in 2005, 11 years before SHA1 attacks were known, so it used regular SHA1. The collision detector was added in 2017 and nothing broke, because false positive chance is 2^-90 [1].
I have not heard of any new SHA1 collision results, but if they are based on no-difference differential paths, git has nothing to worry about. And if they are not, it may be possible to extend DC detector to seamlessly detect and prevent those attacks, and then only upgrade git clients, keeping backward and forward compatibility for data.
Of course there is always a chance that someone will come out with all-new SHA1 preimage attack that cannot be detected without high rate of false positive, so it's prudent to switch git to sha256. There is a lot of work being done: git's sha256 mode went out of beta in 2.42 (2023), but neither github nor gitlab support it.
But since the current state of git's sha is that there is nothing broken, and git git commit hash _is_ "enough to know you are distributing/executing the legitimate code, as opposed to a malicious doppelganger", there is no real pressure.
[0] https://marc-stevens.nl/research/papers/C13-S.pdf
[1] https://github.com/cr-marcstevens/sha1collisiondetection
Its not detecting "intent" it is detecting that the hash is one vulnerable to the attack, which is extremely unlikely to happen by accident, so if you see it you can assume malice.
It might be a band-aid, and sha256 is certainly a much better solution, but its more robust than it sounds at first glance (since it sounds crazy at first glance)
Sure it's plaster, but plaster can last a good while. Sufficiently new attacks don't come around all that often, and every hash has a risk of new attacks showing up.
fwiw, I wasn't too familiar with this usage, looked it up and sticking plaster is in the sense of bandaid here https://en.wikipedia.org/wiki/Adhesive_bandage
But agreed that it's a rather tougher patch than I'd originally thought, reading elsewhere in this thread.