SHA-1 Hash Generator

How SHA-1 Works

SHA-1 was designed by the NSA and published by NIST in 1995 as FIPS 180-1. It was a corrected reissue of SHA-0, which had appeared two years earlier and was quietly withdrawn. The only structural difference between them is a single extra one bit left rotation in the message schedule, an amendment that turned out to matter a great deal for the algorithm's resistance to differential attacks.

Like MD5 it is a Merkle-Damgard hash. The message is padded with a 1 bit, then zeros, then a 64-bit big endian length, until the total is a multiple of 512 bits. Each 512-bit block is then processed in turn, with the compression function taking the current state and the block and producing the next state.

Where SHA-1 differs meaningfully from MD5 is the message schedule and the round count. The sixteen 32-bit words of a block are expanded into eighty words: each new word is the XOR of four earlier words, rotated left by one. Those eighty words feed eighty rounds, organized as four groups of twenty. Each group uses its own boolean function (choice, parity, majority, parity again) and its own additive constant. Every round rotates the state, mixes in a message word, and adds a constant.

The internal state is 160 bits, held as five 32-bit words labelled A through E, larger than MD5's four words. When every block has been consumed, those five words are concatenated big endian and printed as hexadecimal, giving a 160-bit digest that is always 40 hexadecimal characters long. The extra 32 bits of output over MD5 and the jump from 64 to 80 rounds bought SHA-1 roughly a decade of extra service life, but the underlying construction is close enough to MD5 that the same family of attacks eventually caught up with it.

SHA-1 Properties

The specification numbers for SHA-1. Note the 40 character output length, which is the quickest way to identify a SHA-1 digest in a log file or database column.

SHA-1 sits awkwardly in the middle of the field. It is too weak to deploy in anything new, yet it is embedded in so much existing infrastructure, Git being the obvious example, that it cannot simply be deleted from the world.

Example SHA-1 Hashes

Verified SHA-1 digests for three short inputs. The abc value is the test vector printed in the original FIPS publication, so it is the standard first check when validating a new implementation.

You can reproduce every one of these in the generator above. Try appending a single space to hello and hashing again: the two digests share no visible structure, even though the inputs differ by one byte. That total decorrelation is the avalanche effect, and it is what makes a hash useful as a fingerprint even when the algorithm is no longer trustworthy against a motivated adversary.

What SHA-1 Should and Should Not Be Used For

SHA-1 is deprecated for security, but it is not gone. The honest position is that it remains acceptable as a content address or a legacy compatibility format, and unacceptable anywhere a signature or a trust decision depends on it.

Appropriate uses

• Reading and verifying legacy checksums published before the deprecation, where the alternative is no verification at all.
• Git object identifiers, where SHA-1 is used to address content rather than to defend against an attacker. Git has added collision detection and is migrating toward SHA-256.
• Non-adversarial deduplication and change detection inside a system you fully control.
• Interoperating with older protocols and hardware that simply do not offer anything stronger.

Do not use it for

• TLS certificates. Chrome, Firefox, Edge, and Safari all stopped accepting SHA-1 signed certificates during 2016 and 2017.
• Code signing, document signing, or any digital signature scheme.
• Password storage, for the same speed reasons that rule out MD5.
• Any new system at all. There is no scenario in 2024 or later where a greenfield design should pick SHA-1 over SHA-256.

The turning point was February 2017, when researchers at CWI Amsterdam and Google published SHAttered: two different PDF files, showing visibly different content, that produced exactly the same SHA-1 digest. The attack cost roughly nine quintillion computations, expensive but well within reach of a well funded organization, and costs only fall. In 2020 the SHA-1 is a Shambles work reduced this to a chosen prefix collision, which is the dangerous variety because it lets an attacker pick both documents in advance rather than accepting whatever gibberish the collision search produces.

Why You Should Not Hash Passwords With SHA-1

It is worth separating two different criticisms of SHA-1, because people often conflate them. The collision attacks described above do not directly help anyone recover a password. Password cracking is a preimage problem, not a collision problem, and SHA-1 preimage resistance is still standing.

SHA-1 is nonetheless a terrible password hash, for the same reason MD5 is: throughput. A general purpose hash function is engineered to run as fast as the hardware allows, because in its intended use, hashing multi gigabyte files, speed is the whole point. Turn that same function on an eight character password and an attacker with a modern GPU rig can test tens of billions of candidates per second. Real world password distributions are heavily clustered, so most user chosen passwords fall in the first few billion guesses.

Salting is mandatory but insufficient. A unique random salt per user stops one cracked hash from revealing every account that shares that password, and it invalidates precomputed lookup tables. What it cannot do is make each individual guess cost more. Only a purpose built key derivation function does that.

Choose Argon2id if your platform supports it, since it is memory hard and therefore resists the GPU and ASIC parallelism that makes SHA-1 cracking cheap. bcrypt and scrypt are both solid alternatives with long deployment histories. If you are stuck with a hashing primitive rather than a full KDF, PBKDF2 with a high iteration count is the fallback, and it is what SHA-1 was most defensibly used for in older systems such as WPA2. Even then, migrate when you can.

HMAC and SHA-1

HMAC is a construction that turns a plain hash function into a keyed one. It hashes the message twice, once with the secret key mixed into an inner pad and once with the key mixed into an outer pad, which is what protects it from the length extension attacks that Merkle-Damgard hashes are otherwise vulnerable to. The result proves two things at once: that the message was not altered, and that it came from someone holding the key.

HMAC-SHA1 is unusually resilient given the state of bare SHA-1. HMAC security does not depend on collision resistance, so the SHAttered result does not break it, and no practical forgery against HMAC-SHA1 is known. That is why it survives in places bare SHA-1 does not: TOTP two factor codes as specified in RFC 6238 use HMAC-SHA1 by default, as did older AWS request signing and OAuth 1.0a.

None of that makes it a good choice for new work. NIST has deprecated SHA-1 across the board, auditors flag it on sight, and the migration cost from HMAC-SHA1 to HMAC-SHA256 is close to zero. Use HMAC-SHA256 unless a protocol you do not control forces your hand. The generator above supports HMAC mode with a secret key if you need to produce or check one.

If you are migrating away from SHA-1, the developer tools directory has SHA-256 and SHA-512 generators for the replacement digests, an MD5 generator for legacy comparison, and JWT, Base64, and URL encoding utilities for the surrounding plumbing.