SHA1 Hash Generator

SHA-1: The Hash That Secured the Early Web

SHA-1 (Secure Hash Algorithm 1) was designed by the National Security Agency and published by NIST in 1995 as FIPS PUB 180-1. It produces a 160-bit hash displayed as 40 hexadecimal characters. For over a decade, SHA-1 was the cryptographic backbone of the internet: SSL/TLS certificates used it for digital signatures, software vendors signed code releases with it, Git version control built its entire data model around it, and PGP/GPG signatures relied on it for email authentication. Enter any text above to generate its SHA-1 hash. While the tool functions correctly, be aware that SHA-1 is deprecated for all security applications.

The 2017 Collision and What It Means

In February 2017, researchers from Google and CWI Amsterdam announced SHAttered: the first practical SHA-1 collision. They produced two different PDF files with identical SHA-1 hashes. The attack required approximately 6,500 years of single-CPU computation, executed in practice through a massive distributed GPU effort costing an estimated $110,000 in cloud computing resources at the time. This cost has only decreased since then as GPU hardware improves. The collision broke SHA-1's fundamental guarantee: that no two different inputs should ever produce the same output. Subsequent research has produced chosen-prefix collisions (where the attacker can control both colliding inputs' prefixes), making the threat even more practical for real-world document forgery. Major browsers began rejecting SHA-1 certificates in 2016, and certificate authorities stopped issuing them. SHA-1 is now considered broken for all security applications without exception.

Git's Deep Dependency on SHA-1

Git identifies every object (commit, tree, blob, tag) by its SHA-1 hash. A commit hash like a1b2c3d4e5f6 is a truncated SHA-1 of the commit contents including the tree hash, parent commits, author, and message. The SHAttered attack raised legitimate concerns: theoretically, an attacker could create a malicious file with the same SHA-1 hash as a legitimate repository object, substituting it without detection. In practice, Git added collision detection that identifies inputs crafted using the SHAttered technique and rejects them. The Git project is transitioning to SHA-256 as an alternative hash (available since Git 2.29 as an experimental option), but the migration is extraordinarily slow because SHA-1 is embedded in Git's data model, wire protocol, every existing repository's history, every tool that parses Git objects, and every CI/CD system that references commits by hash. Full ecosystem transition will take years.

HMAC-SHA1 and TOTP: Still Acceptable in Specific Contexts

While SHA-1 as a standalone hash is broken, HMAC-SHA1 (Hash-based Message Authentication Code using SHA-1) remains cryptographically secure. The HMAC construction's security does not depend on the underlying hash function's collision resistance - it depends on its pseudorandomness properties, which SHA-1 still provides. This is why TOTP (Time-based One-Time Passwords) used in two-factor authentication apps like Google Authenticator still use HMAC-SHA1 (as specified in RFC 6238) without security concerns. Similarly, PBKDF2-HMAC-SHA1 for key derivation remains acceptable though newer alternatives are preferred. The distinction is subtle but important: SHA-1 is broken for hashing (where collisions matter) but not for keyed MAC operations (where collision resistance is not required for security).

When You Encounter SHA-1 in Legacy Systems

Enterprise environments are full of SHA-1 dependencies. Internal certificate authorities that issued SHA-1 certificates to printers, network appliances, and IoT devices. Custom applications that verify file integrity using SHA-1 checksums embedded in databases. Backup systems that deduplicate using SHA-1 content addressing. Build systems that cache compilation outputs keyed by SHA-1 hashes of source files. For each legacy SHA-1 usage, evaluate whether the hash serves a security function (authentication, integrity verification against adversaries, digital signatures) or a non-security function (deduplication, caching, content addressing, change detection). Security functions must be migrated to SHA-256 as a priority. Non-security functions can continue using SHA-1 with the understanding that it provides no cryptographic guarantees but works perfectly well for detecting accidental changes and generating deterministic identifiers. Prioritize migration by risk: certificate signing and authentication first, file integrity verification second, non-security uses last or not at all.

Frequently asked questions