Hash Generator

A matching hash proves integrity, never authenticity

A digest that matches proves the bytes you have are the bytes the digest was computed over. It proves nothing about who computed it — an attacker who can replace the download can replace the checksum printed next to it, and then both match.

Authenticity needs a key in the loop: a signature over the digest with a key you already trust, or an HMAC when both sides share a secret. Run the bare hash anyway — a truncated download is far more common than a compromised mirror — knowing which of the two you ruled out.

Three limits of this page specifically

• It hashes text, not a file. The input is the UTF-8 bytes of the box. sha256sum and Get-FileHash hash the file's bytes, so a single trailing newline your editor added changes every character of the digest. Pasting a file in here will not verify a download.
• There is no MD5, and cannot be. Web Crypto deliberately does not implement it. When a vendor publishes only MD5 for a firmware image you need a local command instead.
• None of the four is a password hash. SHA-256 is designed to be fast, which is the opposite of what you want against a GPU. Passwords need a slow, salted KDF — Argon2, scrypt or bcrypt.

Which of the four to pick

• SHA-256 is the right default — file integrity, certificate fingerprints, request signing, image digests. SHA-512 is often faster on 64-bit hardware; SHA-384 is its truncation.
• SHA-1 is here for reading, not writing. Practical collisions exist, so a match no longer proves the content is the content. Comparing against an existing system — a Git object ID, an appliance fingerprint — is fine; choosing it for something new is not.

To read a certificate's fingerprint off a live handshake use the SSL checker or, across many hosts, ssl-cert-checker. crypto-policy-checker audits the algorithms in use, and crypto-agility covers changing them when the next one falls.