MD5 Generator

MD5 — Message Digest 5 — is a hash function published by Ronald Rivest in 1992. It reduces any input, of any length, to a fixed 128-bit fingerprint, written as 32 hexadecimal characters.

1""                          →  d41d8cd98f00b204e9800998ecf8427e2"abc"                       →  900150983cd24fb0d6963f7d28e17f723"abd"                       →  4911e516e5aa21d327512e0c8b1976164a 4 GB video file           →  32 characters, just the same

Notice the second and third lines. One character changed, and the digest is entirely different — there is no partial resemblance between the hashes of similar inputs. That is what makes a hash useful for spotting change.

MD5 was designed as a cryptographic hash, and it no longer qualifies as one. Collisions have been practical since 2004. It survives because it is fast, short and printed next to a great many downloads — so reading those checksums still requires computing it.

1. 1. Pad the message. Append a single 1 bit, then zeros, until the length is 64 bits short of a multiple of 512 — then append the original length in bits. Every message becomes a whole number of 512-bit blocks.
2. 2. Start from four fixed words. A, B, C and D are initialised to constants written into the specification.
3. 3. Process each block in 64 steps. Four rounds of sixteen, each mixing the block into the state with a different non-linear function, a rotation and a constant drawn from the sine table.
4. 4. Add the result back into the state and move to the next block. This is why hashing can be incremental: the state is all that carries between blocks, so a file can be read a slice at a time.
5. 5. Emit the four words as 32 hexadecimal characters, little-endian.

That incremental step is what lets this page hash a multi-gigabyte file without loading it into memory: it reads four megabytes, folds them into the state, discards them and moves on.

Collision attacks

In 2004 Wang and Yu published a method for producing two different inputs with the same MD5. What was hours of computation then is seconds now. Researchers have demonstrated colliding pairs of executables, PDFs and even X.509 certificates — documents that differ meaningfully while sharing a digest. If someone mightwant two files to hash the same, MD5 cannot stop them.

Not suitable for password storage

MD5 is fast, and a general-purpose graphics card computes billions of MD5s per second. A stolen table of MD5 password hashes is cracked in hours — how many hours depends on the passwords, which is the number the password strength checker estimates. Password hashing needs a function that is deliberately, tunably slow — and salted, which MD5 is not on its own.

Not recommended for digital signatures

A signature signs a hash, not a document. If two documents can share a hash, one signature covers both — which is exactly how a forged certificate authority was demonstrated in 2008. Signature schemes moved to SHA-256 for this reason.

A legacy algorithm

Standards bodies have deprecated MD5 for security use for over a decade, and browsers dropped it from their crypto APIs. It persists in checksums, cache keys and older systems, and that is the only place it belongs.

• Use SHA-256 or SHA-512 for anything new. Both are in every standard library and in the browser itself, and the hash generator computes either here. There is no reason to reach for MD5 unless something you do not control already uses it.
• Never use MD5 for password hashing. Not with a salt, not with many iterations, not with a secret pepper. The algorithm is the wrong shape for the job — it is built to be fast.
• Use bcrypt, Argon2 or PBKDF2 for passwords. They are designed to be slow and to have their cost tuned upwards as hardware improves. Argon2 is the current recommendation; bcrypt remains perfectly respectable.
• MD5 is still fine for integrity verification. Checking that a file arrived intact, spotting duplicates, noticing that a backup changed — for all of these the threat is corruption, not an adversary, and MD5 handles it.
• Prefer a signature to a checksum when authenticity matters. A checksum published on the same page as the download proves nothing if the page itself was compromised. A signature checked against a key you already trust does.
• Never treat a hash as encryption. Hashing is one-way and lossless of nothing — it discards. A hash of a short or predictable value is recoverable by simply hashing guesses, which is how rainbow tables work.
• Compare hashes in full. Checking the first and last few characters is a habit worth losing; crafted collisions aside, it defeats the point of comparing at all.