Git 3.0's upcoming SHA-256 default will be a costly mistake

The upcoming Git 3.0 release is set to introduce SHA-256 as the default content hashing algorithm, which Git has used as SHA-1 since its inception in 2005. This change, though touted as providing stronger security, may prove to be an expensive and unnecessary global nightmare.

The argument against SHA-1 is that it has been considered semi-broken since 2017, when collision attacks were published (SHAttered, SHA-1 is a Shambles). However, these attacks, while theoretically possible, are not practically exploitable, unlike the theoretical concern with SHA-256.

Git's SHA-1 algorithm has never produced two different files with the same hash, which would be considered a collision. This process, known as a collision attack, is theoretically possible with SHA-1 but not with SHA-256. However, a second-preimage attack, where an attacker creates a malicious file with the same hash as a benign one, is considered more concerning. While this attack is theoretically possible with SHA-1, it is highly improbable with SHA-256.

Despite these theoretical risks, the shift to SHA-256 may cause significant inconvenience and cost for the vast number of Git repositories worldwide. The cryptographic integrity that SHA-1 provides, by hashing potentially millions of file contents, trees, and commits, could be lost with the switch to SHA-256. This change could lead to a significant disruption for users and developers, with little to no practical benefit.