SHA-1 (Secure Hash Algorithm 1) is a cryptographic hash function, originally designed by the U.S. National Security Agency. Its purpose is to output a unique hash value (a seemingly random string of numbers and letters) that represents a specific data set; at least, that’s how it was intended to work. SHA-1 has been used for digital signatures, file integrity verification, and protecting digital assets like credit card transactions, open-source software repositories, and much more.
Now, thanks to the Netherlands’ Cryptology Group at Centrum Wiskunde & Informatica (CWI) and the Google Research Security, Privacy and Anti-Abuse Group, SHA-1’s weakness has been exposed through documented proof of a collision. A collision occurs when two different data sets are input into a one-way function and the same hash output is delivered. This isn’t entirely impossible (a collision is a natural, albeit rare, occurrence when mapping an infinite set to a finite set) but the purpose of SHA-1 was to make creating a collision technologically and financially unfeasible.
According to Google/CWI, it’s “now practically possible to craft two colliding PDF files and obtain a SHA-1 digital signature on the first PDF file which can also be abused as a valid signature on the second PDF file.” The research team was able to create two PDF files that displayed different content, but output the same SHA-1 hash. To help people understand what they did, the two companies provided an infographic detailing their attack, and released a white paper for the more technically-inclined.
Google and CWI may have generated the first known collision, but SHA-1’s security vulnerabilities have been known since 2005. Bruce Schneier, a computer scientist, found a technique that would be able to attack SHA-1 about 2,000 times faster than a brute-force attack (which would take a single CPU millions of years to perform). In 2005, technology was at a point where attacking SHA-1 using his method was “just on the far edge of feasibility,” according to Schneier. Google and CWI’s method of attack, using today’s technology, is over 100,000 times faster than trying to brute-force attack SHA-1.
Creating A Collision
SHA-1 is still somewhat safe, at least for now, due to the fact that an attacker would need access to significantly advanced technology, vast amounts of funding, or a combination of both. It took Google and CWI two years of collaboration to generate the first verifiable collision. According to their announcement, which is posted on shattered.it, the “attack required over 9,223,372,036,854,775,808 SHA-1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations.”
That’s over nine quintillion computations, which is much more than the average (or even an expensive) personal computer could efficiently handle. An odd and interesting fact about the specific number 9,223,372,036,854,775,808—that number is exactly the odds of a person filling out a perfect March Madness bracket. It can also be written simply as 2^63.
As technology advances at an ever-accelerating pace, the potential for an attacker to create SHA-1 collisions increases with time. That’s why a proof is so important; it shows that this type of attack is possible. Now that SHA-1’s vulnerability has been empirically proven, systems will hopefully begin using newer, more secure hash functions. This is vitally important for mitigating fraudulent activity.
With sufficiently advanced technology and some technical know-how, a landlord could create two colliding PDF files of a rental agreement. Since the colliding PDFs would have the same hash (if SHA-1 is used), the landlord could trick a tenant into digitally signing a high-rent contract, by first having them sign a low-rent agreement, then simply presenting the identically hashed high-rent agreement as the “true” version.
Do SHA-1 Security Concerns Affect Ethereum?
According to Google, the newest version of Chrome considers any website using a SHA-1 certificate as insecure. Firefox is allegedly rolling out a similar change to its web browser. Since the vulnerability of SHA-1 was theorized back in 2005, and the hashing algorithm was officially deprecated by the National Institute of Standards and Technology (NIST) in 2011, many current systems have moved on and rely on more advanced encryption (though many applications still rely on SHA-1, thus the reason Google sought to prove its insecurity).
Ethereum is one of those projects currently using a more secure form of encryption. For hashing, Ethereum uses an algorithm known as Keccak-256. Confusingly, Ethereum referred to their algorithm as SHA-3 for some time, until the nomenclature was adjusted for clarity’s sake, and to ease the onboarding of new developers.
Ethereum’s Hudson Jameson gives a more technical explanation on Ethereum’s Stack Exchange, writing:
According to this, NIST changed the padding to SHA3-256(M) = KECCAK  (M || 01, 256); which was different than the original padding proposed by the Keccak team. It seems that now people are calling the ‘original’ SHA3 Keccak hashing ‘Keccak’ and the new NIST SHA3 standard as ‘SHA-3’.”
Essentially, the “official” SHA-3 wasn’t released until August 2015, but Ethereum’s development started in December 2013, which is why Ethereum effectively forked the unfinished SHA-3 into the Keccak-256 version.
Keccak-256 (and SHA-3) is still considered secure. Regarding proof-of-work and mining, Ethereum uses a bespoke algorithm called Ethash, which is also more secure than SHA-1. In conclusion, while SHA-1 may have been “broken,” your Ether is still safe.