SHA-1 Collisions: The SHAttered Reality

The SHAttered attack doesn’t break SHA-1 for most common uses, but it does shatter its viability for critical security functions like SSL certificates.

Let’s see SHA-1 in action, or rather, its absence. Imagine you’re browsing a secure website. Your browser checks the site’s SSL certificate. This certificate has a digital signature, created using a hashing algorithm like SHA-1. The browser then re-calculates the hash of the certificate’s content and compares it to the signature. If they match, the browser trusts the certificate and the connection is secure.

The problem is, the SHAttered attack, demonstrated by Google and CWI Amsterdam, found a way to create two different files that produce the exact same SHA-1 hash. This is called a collision.

Here’s how a collision fundamentally undermines the trust model:

1. Legitimate Certificate: A Certificate Authority (CA) creates a legitimate SSL certificate for www.example.com. They sign it using SHA-1. Your browser verifies it. All good.
2. Malicious Certificate: An attacker creates a different, malicious certificate (e.g., for a phishing site impersonating www.example.com). Crucially, they manage to craft this malicious certificate such that it has the exact same SHA-1 hash as the legitimate one.
3. The Attack: The attacker then presents this malicious certificate to your browser. Your browser performs the hash calculation and signature verification. Because the hash matches the legitimate certificate’s hash, and the signature is valid for that hash, the browser incorrectly believes the malicious certificate is legitimate.

This isn’t theoretical. The SHAttered team achieved a practical SHA-1 collision. They used:

• Massive computational power: Equivalent to thousands of CPUs running for months, or hundreds of GPUs for a similar period.
• A differential attack: This technique exploits specific mathematical weaknesses in the SHA-1 algorithm to find two distinct inputs that produce the same output. They essentially found a "shortcut" to generate two messages that would result in identical hash values.

Why is this a big deal?

SHA-1 was designed to be a one-way function. Given an input, it’s easy to compute the hash. Given a hash, it’s computationally infeasible to find the original input (pre-image resistance). It was also designed to be infeasible to find two different inputs that produce the same hash (collision resistance). SHAttered breaks collision resistance.

What does this mean for you?

• SSL/TLS Certificates: This is the most immediate impact. Browsers and operating systems have been deprecating SHA-1 for years, and SHAttered is the final nail in the coffin. Major CAs stopped issuing SHA-1 certificates around 2016. If you’re still encountering SHA-1 signed certificates, they are a significant risk and should be treated with extreme suspicion.
• Digital Signatures: Any system relying on SHA-1 for verifying the integrity of signed documents or software is vulnerable. If an attacker can create a malicious file with the same SHA-1 hash as a legitimate one, they can substitute their malicious content undetected.
• Integrity Checks: While less critical than security certificates, SHA-1 is still used in some places for simple file integrity checks. A collision means these checks can be bypassed.

What SHA-1 is not broken for (yet):

• Pre-image attacks: Finding the original message given only the SHA-1 hash. This is still considered computationally infeasible.
• Brute-force password hashing: If you’re using SHA-1 with a salt, the attack doesn’t directly apply. The salt makes it much harder for attackers to use pre-computed rainbow tables or to leverage collision findings effectively against individual user passwords. However, even here, SHA-1 is outmoded and stronger algorithms like Argon2 or bcrypt should be used.

The Fixes:

The solution is to migrate away from SHA-1 entirely for any security-sensitive application.

1. SSL/TLS Certificates:

   • Diagnosis: Check certificate details in your browser (click the padlock icon). Look for "Signature algorithm." If it’s sha1WithRSA, you have a problem.
   • Fix: Obtain new certificates signed with SHA-256 (or stronger). For example, when generating a Certificate Signing Request (CSR) with OpenSSL, ensure your configuration uses SHA-256. If you’re a server administrator, renew your certificates. If you’re a user, report such sites to the CA or browser vendor.
   • Why it works: SHA-256 is a different algorithm with a larger hash output and no known practical collision vulnerabilities.

2. Software Signing:

   • Diagnosis: If you’re verifying software downloads, check the digital signature. A command like signtool verify /pa your_file.exe on Windows might show sha1 as the signature algorithm.
   • Fix: Publishers must re-sign their software using SHA-256 or stronger. For developers, use signtool sign /n "Your Certificate Name" /fd sha256 your_file.exe (or similar commands for other signing tools) to sign with SHA-256.
   • Why it works: The verification process will then check against a SHA-256 hash, which cannot be forged by the SHAttered attack.

3. General Digital Signatures (e.g., document signing):

   • Diagnosis: Use forensic tools or specific cryptographic libraries to inspect the signature algorithm used.
   • Fix: Re-sign documents using SHA-256 or stronger hashing algorithms. For example, if using OpenSSL for signing: openssl dgst -sha256 -sign private.key -out signature.bin original_document.txt.
   • Why it works: This ensures the integrity check is based on a collision-resistant hash function.

The next error you’ll likely encounter after fixing SHA-1 issues is related to the deprecation of older TLS versions (like TLS 1.0 and 1.1), which often go hand-in-hand with legacy cryptographic practices.