Git developers release test code to transition away from aging SHA-1 hashing

Slow progress with forklift upgrade

Git, the popular distributed software version control system, is taking the first tentative steps in what promises to be a tricky migration between the aging SHA-1 hashing algorithm and a more secure alternative.

Reliance on SHA-1 has been baked into how Git works since its creation by Linus Torvalds way back in 2005 as a system to track changes in source code for the Linux kernel.

The hashing algorithm is used mainly for identification of a changeset related to different software builds.

Git uses SHA-1 to identify revisions and guard against accidental corruption, rather than as a cryptographic or security function, another application of hashing technology.

Collision avoidance

Hashing functions take an input and process it to give a fixed size hash value or message digest. Security researchers at CWI Amsterdam and Google first demonstrated in 2017 that it was possible for two different files to give the same SHA-1 hash – known as a “collision”.

Exploits based on this shortcoming have been refined over the three years, to the point where other researchers recently demonstrated a way to append data to two existing documents in such a way that they return the same SHA-1 hash. This is known as a “chosen-prefix collision”.

Because of the heavy number crunching needed to generate a chosen-prefix collision, each instance costs around $45,000 to compute, but this figure is only going to decrease over time.

Advances mean the SHA-1 hashing protocol is potential susceptible to types of attacks long possible against the earlier MD5 hashing protocol.

Moving on

The writing has been on the wall for SHA-1 for some time. Web browser vendors such as Mozilla dropped support for SHA-1 SSL certificates back in 2017.

Git is following suit with plans to upgrade to SHA-256 throughout the repository. The move, which is far from straightforward, safeguards against the potential risk of hard-to-detect tampering.

Hashing is not the only security mechanism in play on Git, so even though the upgrade to SHA-256 is desirable, it is far from essential.

The long-planned upgrade is tricky because it involves a change in a core component of the system while maintaining backwards compatibility with existing software repositories.

The broad plan, first outline three years ago, was fleshed out through a posting last month by Git developer Brian Carlson, who described the proposed SHA-256 implementation and inviting comment from other experts on transition code.

This code is at an alpha stage of development and not yet ready to apply to working repositories.

An analysis by Jonathan Corbet of Linux and free software news site LWN.net outlines the situation:

SHA‑1 is now considered to be broken and, despite the fact that it does not yet seem to be so broken that it could be used to compromise Git repositories, users are increasingly worried about its security.

The good news is that work on moving Git past SHA‑1 has been underway for some time and is slowly coming to fruition; there is a version of the code that can be looked at now.

Moving to a stronger hash is a tricky migration because, as Corbet outlines, in the early days of Git, Torvalds was “unconcerned about the possibility of SHA‑1 being broken”.

“As a result, he never designed in the ability to switch to a different hash; SHA‑1 is fundamental to how Git operates,” Corbet said.

READ MORE Researchers demonstrate practical break of SHA-1 hash function