Comment

Comment by GrantMoyer

Git moved to a modified SHA-1 (let's call it SHA-1′) back in 2017 which prevents the particular attack described in SHAttered, so the SHA-1′ object names and signatures can be trusted for now. But the known collision attack on the underlying algorithm makes it more likely for SHA-1′ to be broken in the future too. Researchers could find variations or improvements of the weaknesses used in SHAttered to attack SHA-1′ as well. In other words, there are no known practical collision attacks, but there are known avenues of reasearch that could lead to practical collision or second-preimage attacks being discovered.

The idea, then, is to migrate all git history to a stronger hash before that happens. If we waited until an attack was found, it'd be too late; all git history would be suspect forever into the future (disregarding extensive auditing), even if a stronger hash was used retroactively. Full SHA-256 doesn't have known practical collision attacks, and it doesn't even have known research avenues likely to lead to practical collision attacks, so is considered more future-proof than SHA-1′.

This idea of future-proofing is common in cryptography. For example RSA-1024 keys are now considered practical to factorize (with a supercomputing cluster and a few months), but that's okay, because, foreseeing the possibility, "everyone" switched to RSA-2048 or stronger a decade ago. Now we're adopting new key algorithms to protect against possible quantum computing attacks in the future.

parent GrantMoyer 29 days ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton