……SHA-2 is a family name, not a hash function call. Paste text or drop a file, read SHA-224, SHA-256, SHA-384 and SHA-512 grouped by engine, then name a published checksum by how many characters it has.
Empty string. Every SHA-2 member has a defined digest for zero bytes.
…………Open Node and run crypto.createHash('sha2'). It throws. OpenSSL -sha2 does the same. Java MessageDigest.getInstance("SHA-2") fails. The string SHA-2 names a family published in FIPS 180-2. It is not a compression function you pass to a library.
A requirements doc that says “hash with SHA-2” leaves the next engineer guessing. Most guess SHA-256. TLS cipher suites, JWT alg values, and checksum filenames all name a member. Guessing the wrong one produces a digest nobody else agrees with, while both sides believe they followed the spec.
Write the member. SHA-256, SHA-384, SHA-512, or SHA-224. SHA-2 is a chapter title.
# these fail
openssl dgst -sha2 release.tar.gz
node -e "require('crypto').createHash('sha2')"
# these are the ids libraries accept
openssl dgst -sha256 release.tar.gz
openssl dgst -sha384 release.tar.gz
openssl dgst -sha512 release.tar.gz
openssl dgst -sha224 release.tar.gzSHA-2 is two hash functions wearing four labels. The board above groups them that way on purpose.
Hashing one input into all four at once shows the split. SHA-224 and SHA-256 move together because they share an engine. SHA-384 and SHA-512 move together for the same reason. Crossing the engines never produces a prefix match.
People expect the short hashes to look like the start of the long ones. They never do.
Two more names sit in FIPS 180-4: SHA-512/224 and SHA-512/256. Both run the 64-bit engine with yet another pair of IVs. This page leaves them out. Their hex strings are the same width as SHA-224 and SHA-256, which is how they get swapped in code reviews.
Take the SHA-256 row. Keep the first 56 hex characters. That string is not SHA-224.
SHA-224 seeds eight 32-bit words that FIPS 180-4 lists separately from SHA-256. After 64 rounds the engine holds 256 bits, then drops the last 32. Because the start state differed, every round differed, so the surviving 224 bits have no overlap with a sliced SHA-256 digest.
SHA-384 versus SHA-512 repeats the same trap on the 64-bit engine. Chopping a SHA-512 digest down to 96 hex characters will not match the SHA-384 row. Interoperability bugs of this kind show up in payment APIs and in CMS signed attributes, usually after two vendors both claim SHA-2 support.
If a protocol says SHA-224, hash SHA-224. Do not truncate SHA-256 and hope.
A SHA-2 digest in hexadecimal is a fixed width. Count first. Compare second.
| Hex chars | Bits | Member you are holding | Same width, different engine |
|---|---|---|---|
| 56 | 224 | SHA-224 | SHA-512/224 |
| 64 | 256 | SHA-256 | SHA-512/256 |
| 96 | 384 | SHA-384 | none in this family |
| 128 | 512 | SHA-512 | none in this family |
| 32 | 128 | MD5, not SHA-2 | leave this page |
| 40 | 160 | SHA-1, not SHA-2 | leave this page |
Base64 changes the widths: 40, 44, 64 and 88 characters, often with padding equals signs. Java and .NET default to Base64. sha256sum and sha512sum default to lowercase hex. A visual mismatch between a 64 character string and an 88 character string is usually encoding, not a corrupt file.
Paste the published value into the identify box on the board. The page names the member from the width, then, if you already hashed an input, checks the matching row. A SHA256SUMS line and a SHA512SUMS line are both welcome. The filename column is ignored.
If you are holding a checksum file right now, paste the hex upstairs before you re-download anything. Width names the member. A wrong member is the cheap explanation. A swapped mirror is the expensive one.
SHA-256 and SHA-512 publish the entire internal state as the digest. Anyone holding sha256(secret || message) resumes the compression function and forges a valid digest for a longer message, without the secret. The attack is called length extension. File checksums are unaffected. Request signatures built as hash(secret + body) are the ones that fail.
SHA-224 and SHA-384 close the hole by dropping part of the state. SHA-512/256 does too. HMAC closes it for every member. If the digest authenticates anything, stop using the naked function. Move to the HMAC Generator.
Password storage is a different refusal. SHA-2 is fast. Fast helps the attacker with a GPU. Argon2id, scrypt, or bcrypt belong there. A $6$ shadow entry is SHA-512-crypt, a stretched construction, not the SHA-512 row on this board.
RS256 in a JWT header is RSA with SHA-256. ES384 is ECDSA with SHA-384. PS512 is RSA-PSS with SHA-512. There is no alg value spelled SHA-2. A library that accepts the family name is inventing a default, and defaults of that kind are how two services sign the same payload and still reject each other.
TLS 1.2 cipher suites bury the member at the end of a long identifier. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 names SHA-384 as the PRF hash. ..._SHA256 names SHA-256. Reading “SHA-2 cipher suite” into a config file is how a handshake fails after a weekend of certificate work that was otherwise fine.
Git is moving object ids from SHA-1 to SHA-256, not to “SHA-2”. The SHA-1 generator still reproduces a blob id. The SHA-256 page covers the new object format. This family board will not match a git object id, because git prefixes the content with a header like blob 12 and a null byte before hashing.
sha256sum and sha512sum stream. Use them for disk images.echo appends a newline. printf does not.The empty-string vectors on the board exist to show a known answer before you trust a live digest. FIPS 180-4 publishes them. SHA-256 of zero bytes is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. If the SHA-256 row disagrees with this value on an empty box, stop and check the browser.
Hashing runs in the tab. Text uses the Web Crypto API for SHA-256, SHA-384 and SHA-512, and CryptoJS for SHA-224, because browsers still omit SHA-224 from Web Crypto. Files are read with FileReader. Nothing is uploaded. Load the page once, cut the connection, and the board keeps working.
A matching digest proves the bytes match a value someone published. Whether the publisher was legitimate is a signature question. No hash page answers it. Check the checksum file’s GPG signature, or use the Checksum Validator when a whole manifest is involved.
OpenSSL has no algorithm id named sha2. SHA-2 is the family. Pass -sha256, -sha384, -sha512 or -sha224. Node crypto.createHash and Java MessageDigest behave the same way. A spec that writes SHA-2 without a member leaves the next engineer to guess, and the guess is usually SHA-256.
Width 64 is SHA-256 in the common case. SHA-512/256 uses the same width and a different engine, so a mismatch against the SHA-256 row on this board is a reason to try that page next. 56 characters is SHA-224 or SHA-512/224. 96 is SHA-384. 128 is SHA-512. 32 is MD5. 40 is SHA-1.
SHA-224 starts from a different set of initial values listed in FIPS 180-4, then drops 32 bits after the rounds finish. Because the start state differed, every round differed. Slicing a SHA-256 digest is a different number, and two vendors claiming SHA-2 support often ship exactly that bug. SHA-384 versus SHA-512 repeats the trap on the 64-bit engine.
SHA-256 unless a profile names another one. SHA-384 if a government checklist or CNSA 1.0 is in play, usually paired with AES-256. SHA-512 when a protocol already publishes SHA512SUMS files, or when you want the 64-bit engine for key derivation. Skip SHA-224 for new work. Its 112-bit collision bound sits under the floor most teams now treat as minimum.
Nine times out of ten a trailing newline is in one side and missing from the other. echo abc feeds four bytes. printf %s abc feeds three. Windows CRLF versus Unix LF rewrites every row for the same looking text. A UTF-8 byte order mark at the start of a saved file does the same. The byte counter above the board is the first place to look.
No. A match proves the bytes equal a published value. It says nothing about who published the value. Check the checksum file signature with GPG, or pin an HTTPS origin you already trust. A swapped mirror with a matching checksum file is an old trick. Hashing never replaces a signature.
No. SHA-256, SHA-384 and SHA-512 call the Web Crypto API inside the tab. SHA-224 uses CryptoJS in the same tab, because Web Crypto still omits it. Files are read with FileReader. There is no upload step. Load the page once and it keeps working with the connection cut.
They run the 64-bit engine with their own IVs, so they are not SHA-224 or SHA-256 with extra speed, and they are not SHA-512 with the end cut off. Their hex widths collide with SHA-224 and SHA-256, which is how they get mixed up. Each has a dedicated generator. This board stays on the four names people write when they say SHA-2.
No. SHA-2 is built for speed, and speed helps the attacker who stole the database. Argon2id is the current recommendation, with scrypt and bcrypt as accepted alternatives. A $6$ value in /etc/shadow is SHA-512-crypt, a stretched construction that uses SHA-512 as a building block. Hashing the same password on this board will not reproduce it.
