Cryptographic Hash Generator

A cryptographic hash is a fixed-size fingerprint of data. Feed a hash function anything — three letters or a three-gigabyte disk image — and it returns the same number of bytes every time. SHA-256 always returns 32 bytes, written as 64 hexadecimal characters.

1SHA-256("abc")2  ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad3 4SHA-256(a 3 GB file)5  …also exactly 64 characters

Four properties make such a function cryptographic rather than merely a checksum:

• Deterministic. The same input always produces the same digest, on any machine, in any language, forever. Without this nothing else works.
• One-way. Given a digest, there is no way to compute the input. Most of the information was discarded — 32 bytes cannot hold a gigabyte.
• Avalanche. Changing one bit of input flips about half the output bits, so similar inputs give unrelated digests.
• Collision resistant. Two inputs sharing a digest must exist — infinitely many inputs, finitely many digests — but nobody should be able to find a pair.

That last one is where MD5 and SHA-1 failed. Neither became reversible; both became collidable, which is enough to make them useless for proving that two things are the same.

Nearly every hash here works the same way at a high level. The input is padded to a whole number of blocks, and the blocks are absorbed one at a time into a small internal state. Each block is mixed into the state through many rounds of rotations, additions and exclusive-ors. When the input runs out, the state — or part of it — is the digest.

1input ──▶ pad to block size ──▶ ┌──────────────┐2                                │ compress ×N  │◀── one block at a time3                                └──────┬───────┘4                                       ▼5                                 internal state ──▶ digest

Two consequences follow directly from that shape, and both matter in practice.

Hashing can stream. Because blocks are absorbed one at a time, nothing ever needs the whole input in memory. That is why this tool can hash a file larger than your available RAM, and why it can show progress while it does.

The length is fixed by the state, not the input. The digest is a snapshot of a fixed-size state, which is exactly why the output size never varies and why the original cannot be recovered.

The avalanche effect is easiest to see rather than describe. One letter changes, and nothing survives:

1…over the lazy dog  →  d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e5922…over the lazy cog  →  e4c4d8f3bf76b692de791a173e05321150f7a345b46484fe427f6acc7ecc81be

SHA-3 is the exception to the picture above. Instead of a compression function it uses a sponge: input is absorbed into a much larger state, then output is squeezed back out. The practical difference is that a sponge does not leak its internal state in the digest, which is why SHA-3 has no length-extension weakness — see the best practices below.

They are not variants of one idea. They have opposite goals, and confusing them is behind a good share of security incidents.

1Encryption   plaintext ──key──▶ ciphertext ──key──▶ plaintext     reversible2Hashing      input ────────────▶ digest ─────✗─────▶ nothing        one-way

• Encryption is reversible by design. The entire point is that the holder of the key gets the original back. Confidentiality is the goal.
• Hashing discards information. There is no key, and no amount of computation recovers the input, because the input is no longer there. Integrity is the goal.
• Encryption preserves size; hashing fixes it. Ciphertext grows with the plaintext. A digest never changes length.

So “decrypt this hash” is not a hard problem — it is not a problem at all. What the person usually means is guessing: hash a list of likely inputs and see if any match. That works when the input space is small, which is why it works on passwords and not on files — and why the password generator reports entropy and an estimated crack time, which is a measure of exactly how large that space is.

A third idea sits between them and is often the one actually wanted: message authentication. HMAC combines a hash with a secret key so that a recipient can verify both that data is unaltered and that it came from someone holding the key. Integrity plus authenticity, which a bare hash cannot provide — it is what signs an HS256 token in the JWT generator.

This is what hashes are for, and the workflow is worth stating precisely because the common version of it is subtly useless.

1. 1. The publisher hashes the file and publishes the digest alongside the download.
2. 2. You hash the file you received — drop it onto this page, which reads it locally and never uploads it.
3. 3. Compare. Identical digests mean identical bytes. Paste theirs into the Verify panel and it marks any character that differs.

1$ shasum -a 256 ubuntu.iso22ac1bd0d84cf1a2f27a2b4a2ee3a3c2d…  ubuntu.iso3 4# paste that whole line into the Verify panel —5# the filename after the hash is ignored

Two things this proves, and one it does not:

• It proves the download is not corrupt. A truncated transfer or a failing disk changes the digest completely.
• It proves the bytes match what the publisher hashed — provided the algorithm is not MD5 or SHA-1, where an attacker could construct a different file with the same digest.
• It does not prove the file is genuine.If the checksum came from the same page as the download, whoever could replace one could replace the other. The checksum has to come from somewhere the attacker does not control — a signed release file, a different domain, a package manager’s own database. This is the step most people skip.

Which is why serious distributions sign their checksum file with a GPG key rather than merely publishing it. The signature establishes who wrote the checksums; the checksums establish what the files are.

Never use a general-purpose hash for passwords

This is the most consequential item on the page, so it comes first. Every algorithm in this tool is designed to be fast, and fast is precisely the wrong property for password storage. A modern GPU computes billions of SHA-256 hashes per second, so a stolen table of SHA-256 password hashes is cracked at enormous speed. Adding a salt stops precomputed rainbow tables; it does nothing about raw guessing rate.

• Argon2id — the current recommendation. Tunable in time, memory and parallelism, and its memory cost is what defeats GPUs.
• bcrypt — well understood, available everywhere, still fine. Note its 72-byte input limit.
• PBKDF2 — the conservative choice where a standard requires it. Weakest of the three against GPUs, because it is not memory-hard.

All three are deliberately slow, all three salt automatically, and all three let you raise the cost as hardware improves. That last property is what a plain hash can never offer.

Retire MD5 and SHA-1

• MD5 broke in 2004. Collisions take seconds on a laptop, and chosen-prefix collisions let an attacker make two meaningful files match. Use it only to detect accidental corruption, never to prove two files are the same — the MD5 generator exists for the legacy checksums that still need checking.
• SHA-1 broke in 2017. Two different PDFs with one digest, and by 2020 a chosen-prefix collision cost roughly $45,000. It survives in Git as a naming scheme rather than a security control.
• Both are kept in this tool deliberately — a great many projects still publish MD5 and SHA-1 checksums, and being unable to check them would help nobody. The tool labels them broken wherever they appear.

Choosing among the sound options

• SHA-256 by default. Unbroken, fast, and understood by everything you might need to interoperate with.
• SHA-512 for extra margin when throughput does not matter. Note it is roughly half the speed of SHA-256 in a browser, and about twice the speed on native 64-bit hardware — the opposite ordering.
• SHA-3 when you want a different foundation. Not because SHA-2 is failing, but because depending on one design is a risk in itself.
• BLAKE2 when speed matters in native code. As sound as SHA-3 and faster than MD5 outside a browser.

Mind length extension

Given SHA-256(secret + message) and the length of the secret, an attacker can compute SHA-256(secret + message + suffix) for a suffix of their choosing — without ever learning the secret. Anyone authenticating by hashing a secret joined to data is exposed.

• Use HMAC rather than concatenation. It exists precisely for this, and every platform ships it.
• Or pick a hash that is immune: SHA-224 and SHA-384 truncate their state away, and SHA-3 and BLAKE2 have no extensible state at all.

Compare digests carefully

• Compare all of it. Checking the first and last few characters is a habit worth losing; that is exactly the part an attacker would preserve.
• Get the checksum from a source the attacker does not control — otherwise you are checking a file against a number supplied by whoever gave you the file.
• Use constant-time comparison in code. Not on this page, where both values are on screen and neither is secret, but in any server that compares a submitted MAC — a byte-by-byte early exit leaks the answer through timing.