Hashing & Integrity

Standard hash algorithms include MD5, SHA-1, SHA-256, and SHA-512. MD5 and SHA-1 are both deprecated for security uses due to practical collision vulnerabilities — attackers can construct two different inputs that hash to the same output — though they remain acceptable for non-security uses like basic duplicate-detection checksums.

SHA-2, the family including SHA-256 and SHA-512, remains the standard for file verification, blockchain ledgers, and secure code signatures. SHA-3, a structurally different algorithm standardized later as a hedge against future SHA-2 weaknesses, exists but has seen much slower real-world adoption.

Hash-based Message Authentication Codes (HMAC) combine a hash function with a secret key, producing a code that verifies both data integrity and the sender's identity — unlike a plain hash, which anyone can compute, only someone with the secret key can produce a valid HMAC for a given message. HMACs are widely used in web API request signing, such as AWS's request-signing scheme, to ensure payloads have not been altered or forged in transit.

A hash fingerprint is a practical, everyday application of hashing: an SSH public key, RSA key, or TLS certificate is hashed to produce a short, fixed-length string that is far easier for a human to compare or read aloud than the full key material, while still being cryptographically tied to the exact key it represents.

A common task is verifying a downloaded file has not been corrupted or tampered with. Use the Hash Generator to compute a SHA-256 digest of the file and compare it against the checksum the publisher provided — any difference, even a single changed byte, produces a completely different hash.

When signing or verifying webhook payloads or API requests, use the HMAC Generator to compute the expected signature from the shared secret and payload, and compare it against the signature the sender provided — this confirms both that the payload was not altered and that it actually came from someone who knows the shared secret.

Before connecting to an unfamiliar SSH server or trusting a new SSH key, use the SSH Fingerprint Generator to compute the key's fingerprint and compare it against the fingerprint the server administrator published through a separate trusted channel — never trust a fingerprint that arrives over the same connection you are trying to verify.

If you are choosing a password-hashing algorithm specifically, as opposed to general-purpose data hashing, see the Bcrypt vs Scrypt and Argon2 vs Scrypt comparisons below — password hashing has different requirements (deliberately slow, memory-hard) than the fast, general-purpose hashing this hub otherwise covers.

Mistake: using MD5 or SHA-1 for any security-relevant purpose, including password storage or digital signatures, because they are already in the codebase. Both have practical, demonstrated collision attacks — use SHA-256 or better for integrity, and a dedicated password-hashing algorithm, never a general-purpose hash, for credentials.

Mistake: computing a plain hash instead of an HMAC when the goal is to verify a message came from a specific trusted party, not just that it was not corrupted. A plain hash proves integrity but not origin — anyone can compute a matching hash for altered data; only HMAC, with the shared secret, proves both.

Troubleshooting: if two systems compute different hashes for what looks like the same input, check character encoding (UTF-8 vs UTF-16), line-ending differences (LF vs CRLF), and trailing whitespace first — hash functions are byte-exact, so any of these silent differences produces a completely different digest even though the text looks identical.

Troubleshooting: if an HMAC signature verification is failing intermittently, check whether the payload is being serialized identically on both sides before hashing — a JSON payload with keys in a different order, or different whitespace, produces different bytes and therefore a different HMAC, even though the parsed data is logically the same.

SHA-1 and SHA-2, including SHA-256 and SHA-512, are specified by NIST FIPS 180-4. SHA-3 is specified separately by NIST FIPS 202, using a structurally different sponge-construction design specifically so a future weakness in SHA-2 would not compromise both families simultaneously.

HMAC is defined by RFC 2104, and its use with specific hash functions, such as HMAC-SHA256, is further specified by FIPS 198-1.

SSH key fingerprints are part of the SSH protocol itself, RFC 4716, with SHA-256 as the current default fingerprint format in most modern SSH implementations, replacing the older MD5-based format.

Argon2, the winner of the 2015 Password Hashing Competition, is specified by RFC 9106. Scrypt, an earlier memory-hard password-hashing function, is specified by RFC 7914.

For verifying file integrity or computing a checksum where no secret key is involved, a plain hash, with SHA-256 as a safe modern default, is sufficient. For verifying both integrity and the sender's identity, such as webhook or API request signing, use HMAC instead — a plain hash alone does not prove who sent the data.

For password-specific hashing, do not use a general-purpose hash function like SHA-256 directly — use a dedicated password-hashing algorithm. See the Bcrypt vs Scrypt and Argon2 vs Scrypt comparisons for how the leading options compare technically; see the Authentication & Tokens Lab hub's Decision Guidance for the practical recommendation on which to actually choose for a login system.

For general file or data integrity where speed matters and there is no adversarial threat model, SHA-256 is the standard modern default over SHA-512 unless you specifically need SHA-512's larger digest or are running on 64-bit hardware where it can actually be faster — see the SHA-256 vs SHA-512 comparison for the detail.