Is SHA-1 Quantum Safe?

SHA-1 is NOT quantum safe and is already classically broken.

How SHA-1 Works

SHA-1 (Secure Hash Algorithm 1) was designed by the NSA and published by NIST in 1995 as part of FIPS 180. It produces a 160-bit (20-byte) hash digest and was the dominant cryptographic hash function throughout the 2000s. SHA-1 processes input data in 512-bit blocks through 80 rounds of operations using five 32-bit working variables. The algorithm was used extensively for TLS/SSL certificates, git version control commit IDs, digital signatures (RSA-SHA1, DSA-SHA1), and software integrity verification.

However, theoretical weaknesses were identified as early as 2005, and practical attacks emerged by 2017, rendering SHA-1 cryptographically obsolete.

Quantum Vulnerability Explained

SHA-1 has a demonstrated practical classical collision. In 2017, Google and CWI Amsterdam published SHAttered, two distinct PDF files with the same SHA-1 digest. That is sufficient to disallow SHA-1 for collision-sensitive security uses without forecasting a universal attack cost.

Generic quantum algorithms further reduce idealized search complexity, but the classical collision result already determines the migration decision for signatures and other collision-sensitive uses.

A collision does not automatically forge an arbitrary signature or certificate, but it invalidates the collision-resistance assumption used by many signature and integrity constructions. Exploitability depends on whether the attacker can control the signed inputs and the surrounding format.

Migration Path

SHA-1 requires immediate emergency replacement due to classical vulnerabilities:

Replace with SHA-256 or SHA-384: All SHA-1 hashing should be replaced with SHA-256 (minimum) or SHA-384 (conservative). This includes certificate fingerprints, code signing, integrity verification, and commit hashing.

Git repositories: Git uses SHA-1 for commit IDs. While git's usage is somewhat resilient to collision attacks (due to tree structure verification), the git project is migrating to SHA-256. Organizations should plan git repository transitions to SHA-256.

Legacy certificates: Locate SHA-1 signature use and follow the governing trust-store, revocation, reissuance, and archival-validation rules for that certificate ecosystem.

Software distribution: Package repositories, software update systems, and download verification using SHA-1 checksums provide no integrity protection. Migrate to SHA-256 signatures and checksums.

Industries at Risk

Software supply chains face critical SHA-1 exposure because legacy software distribution systems, package managers, and update mechanisms used SHA-1 checksums. While most have migrated to SHA-256, legacy systems and archived software may retain SHA-1 dependencies.

Git-based development workflows and version control systems used SHA-1 for commit IDs, creating collision-based attack vectors where adversaries could create malicious commits with identical SHA-1 hashes to legitimate commits. The git project is migrating to SHA-256 (git 2.29+), but legacy repositories remain vulnerable.

Certificate authorities and PKI systems issued SHA-1-signed certificates through approximately 2015. While browsers revoked trust in 2017, internal PKI systems and legacy enterprise applications may still trust SHA-1 certificates.

Timeline to Obsolescence

• 2005: Theoretical SHA-1 collision attacks published by Wang et al.
• 2013: NIST deprecated SHA-1 for digital signatures (NIST SP 800-131A).
• 2017: Google demonstrated practical SHA-1 collision (SHAttered attack). Browsers stopped trusting SHA-1 certificates.
• Current control: SHA-1 is disallowed for digital-signature generation under NIST transition guidance. Other uses still require construction-specific analysis.

Remove SHA-1 from collision-sensitive security controls through a governed migration. Assign severity from the construction, attacker control, trust role, exposure, and compensating controls.