Hash Generator

Hashing takes no key and has no inverse. Nothing about a digest is secret: anyone with the same input produces the same output, which is exactly what makes it useful for verification and useless for confidentiality. If the original data has to come back out, you need a cipher.

The consequence people get wrong is password storage. Because the space of human passwords is small, an attacker holding a stolen table does not try to invert anything — they hash candidates and compare. General-purpose digests are engineered to be fast, and that speed belongs to the attacker, not to you. Salting defeats precomputed rainbow tables and does nothing whatsoever about throughput.

Password storage needs a deliberately slow, preferably memory-hard function. OWASP's current baseline is Argon2id at 19 MiB of memory, 2 iterations, and 1 degree of parallelism; scrypt at N = 2^17, r = 8, p = 1 where Argon2id is unavailable; bcrypt at work factor 10 or above for legacy systems, keeping in mind that most bcrypt implementations silently truncate input at 72 bytes; and PBKDF2-HMAC-SHA256 at 600,000 iterations where FIPS-140 compliance forces the choice. None of those is what this tool computes, and none is interchangeable with a bare SHA-256.

MD5 collisions have been practical since Wang and Yu's 2004 result and now take seconds on a laptop. SHA-1 lasted longer: the SHAttered attack from CWI Amsterdam and Google produced the first real collision in February 2017 — two PDFs with different visible content and one identical digest — at a cost of 9,223,372,036,854,775,808 SHA-1 computations. In 2020 Leurent and Peyrin's "SHA-1 is a Shambles" delivered the first practical chosen-prefix collision, running two months on 900 GTX 1060s, estimating the optimised cost at around US$45,000, and using it to forge a PGP key certification.

The operational distinction matters more than the headline. A collision means the attacker controls both inputs: they prepare a benign document and a malicious one that share a digest, get the benign one approved, and substitute the other. What they still cannot do is take a digest you published for a file they never touched and find a second file matching it. That is a second-preimage attack, and no practical one exists against MD5 or SHA-1.

So an MD5 checksum on a mirror page still catches bit rot and still catches a third party tampering with a file an honest publisher created. It does not protect you against the publisher, against any signature scheme where the signer accepts attacker-supplied content, or against anything involving certificates. Git handled its own exposure by adopting Marc Stevens' collision-detecting SHA-1 variant rather than by continuing to trust plain SHA-1.

MD5, SHA-1, SHA-256, and SHA-512 are all Merkle–Damgård constructions: they chain a compression function across padded blocks and emit the final chaining value. That final value is the internal state, so anyone holding a digest can resume the computation from where it stopped.

The practical fallout is that H(secret || message) is not a message authentication code. Given the digest and the length of the secret — not the secret itself — an attacker can produce a valid digest for secret || message || padding || anything they choose. Any API authenticating requests by hashing a shared key concatenated with the parameters can have parameters appended to it, and off-the-shelf tooling automates the padding arithmetic.

HMAC, specified in RFC 2104, exists to close precisely this hole: its nested structure hashes the message under one derived key and then hashes that result under a second, so the output is not a resumable state. Use HMAC-SHA256 and never a bare concatenation. Two families are immune by construction — SHA-3 is a sponge rather than Merkle–Damgård, and the truncated SHA-2 variants SHA-384 and SHA-512/256 discard enough of the final state that it cannot be reconstructed. The same reasoning is why the HS256 signature on a JSON Web Token is an HMAC rather than a hash of the concatenated header and payload.

MD5 emits 128 bits as 32 hex characters, SHA-1 emits 160 bits as 40, SHA-256 emits 256 bits as 64, and SHA-512 emits 512 bits as 128. The length is fixed no matter the input size — a one-byte file and a one-terabyte file produce the same number of characters — and flipping a single input bit changes roughly half the output bits.

That sensitivity is what makes mismatches so confusing to debug. The usual culprit is a trailing newline. MD5 of test is 098f6bcd4621d373cade4e832627b4f6, while MD5 of test followed by a newline is d8e8fca2dc0f896fd7cb4cb0031ba249. Shell pipelines add that newline unless you pass -n to echo, so a digest computed in a terminal routinely disagrees with one computed in an editor for reasons unrelated to the content.

Character encoding is the second culprit. Digests are computed over bytes, so the same visible string encoded as UTF-8 and as UTF-16 produces entirely unrelated output, and a byte-order mark at the start of a file changes its checksum. Two values are worth recognising on sight: d41d8cd98f00b204e9800998ecf8427e is MD5 of empty input and e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is SHA-256 of empty input. Seeing either one means your input never arrived.

Computing the digest correctly and then comparing it carelessly puts the vulnerability straight back. String equality in most languages short-circuits at the first differing byte, so the time taken to reject a wrong value depends on how many leading characters were right. An attacker able to submit many candidate signatures and measure response times can recover the expected digest a byte at a time, never needing the key at all.

Use a comparison whose runtime depends only on length. Node provides crypto.timingSafeEqual(), which works on buffers and throws a RangeError when the two lengths differ; Python provides hmac.compare_digest(); Go provides subtle.ConstantTimeCompare. Convert both values from hex to bytes first, and handle the length check separately so that the mismatch does not become the leak you were trying to avoid.

Across a jittery network this is a difficult attack to land, but it is entirely avoidable and the code path where it bites is one almost every service has: verifying an inbound webhook. Stripe, GitHub, Shopify and most others sign payloads with HMAC-SHA256 and expect the receiver to recompute and compare. That comparison is the one place in a request handler where === is the wrong operator.