SHA-512 Hash Generator

How SHA-512 Works

SHA-512 is the 64-bit member of the SHA-2 family, published alongside SHA-256 by NIST in 2001. Structurally the two are siblings, but almost every parameter is doubled: SHA-512 works on 1024-bit blocks instead of 512, runs 80 rounds instead of 64, and carries an internal state of eight 64-bit words rather than eight 32-bit words.

The padding rule scales accordingly. The message gets a 1 bit, then zeros, then a 128-bit big endian length field, padded out to a multiple of 1024 bits. Each block is split into sixteen 64-bit words, which the message schedule expands to eighty using sigma functions built from rotations and shifts, with rotation amounts chosen specifically for 64-bit operands rather than inherited from SHA-256.

The eight state variables are initialized from the fractional parts of the square roots of the first eight primes, taken to 64 bits of precision, and the eighty round constants come from the cube roots of the first eighty primes. Each round applies the Ch and Maj mixing functions and two large rotation functions, then folds in one schedule word and one constant. After the last block the eight 64-bit words are concatenated to give a 512-bit digest, which prints as 128 hexadecimal characters.

Here is the counterintuitive part, and the reason SHA-512 deserves more attention than it usually gets: on 64-bit hardware it is typically faster than SHA-256 despite producing twice the output. SHA-512 consumes 1024 bits per block against SHA-256's 512, so it needs half as many compression calls for the same input, and it only pays 80 rounds against 64 for each of them. Because its arithmetic is natively 64-bit, every one of those rounds costs a single machine instruction per operation on a 64-bit CPU. The usual measured result is roughly 1.3 to 1.5 times the throughput of SHA-256 on general purpose x86-64 and ARM64 cores. That advantage disappears on 32-bit or embedded targets, where 64-bit arithmetic has to be emulated, and it can also invert on newer chips that carry hardware SHA-256 acceleration instructions but no SHA-512 equivalent.

SHA-512 also serves as the base for several truncated variants. SHA-384, SHA-512/224, and SHA-512/256 all run the same 64-bit core with different initial values and then discard part of the output. SHA-512/256 is a particularly good choice on 64-bit servers: it gives you SHA-256 sized digests at SHA-512 speed, and truncation neatly removes the length extension weakness.

SHA-512 Properties

The specification numbers for SHA-512. The 128 character output makes it unmistakable next to any other common digest.

Collision resistance sits at roughly 256 bits and preimage resistance at roughly 512 bits. Those margins are far beyond anything that could ever be attacked by brute force, and they hold up even against the square root speedup that Grover's algorithm would give a large quantum computer. If you want a hash you will not have to revisit, this is it.

Example SHA-512 Hashes

The canonical SHA-512 test vector. It is the abc digest published in FIPS 180-2 and is the first check any implementation should pass. Note the sheer length: 128 hexadecimal characters is four times an MD5 digest.

Type abc into the generator above and you will get exactly that string back, on any device, in any browser, from any correct implementation. Now change it to abd. The new digest shares no recognizable structure with the old one, because flipping one input bit flips about half the output bits at random. That is the avalanche effect. With 512 bits of output there is a great deal of room for it to work in, which is precisely why SHA-512 digests are so unwieldy to eyeball and so commonly stored in Base64 rather than hexadecimal.

What SHA-512 Should and Should Not Be Used For

Everything SHA-256 is good for, SHA-512 is also good for, usually with better throughput on server hardware. The trade off is size, both in storage and in anything you have to transmit or display.

Appropriate uses

• High volume hashing on 64-bit servers, where the throughput advantage over SHA-256 is real and measurable.
• Digital signatures and certificates, particularly with larger keys, where SHA-384 or SHA-512 pairs naturally with a P-384 or P-521 curve.
• HMAC-SHA512 for message authentication where you want the largest practical security margin.
• Long lived archival integrity manifests, where the data may outlive several rounds of cryptographic advice.
• As the base for SHA-512/256, which gives short digests, SHA-512 speed, and length extension resistance in one package.
• PBKDF2-HMAC-SHA512, notably in Linux crypt with the $6$ prefix, when a full memory hard KDF is not available.

Do not use it for

• Password storage on its own. Being twice the size does not make it any less fast per guess.
• Constrained and embedded environments, 32-bit microcontrollers, and smart cards, where 64-bit arithmetic must be emulated and SHA-256 wins comfortably.
• Anything where digest size matters, such as URL fragments, QR codes, database indexes, or protocol headers. 128 characters adds up quickly.
• Secret prefix message authentication, since like SHA-256 it is a Merkle-Damgard hash and is vulnerable to length extension. Use HMAC or SHA-512/256.

In practice the decision is simple. If the hash runs on 64-bit servers and output size is not a constraint, SHA-512 or SHA-512/256 is the better performing choice. If it runs on embedded hardware, in a browser with hardware SHA-256 acceleration, or anywhere the digest must be short, stay with SHA-256. Both are secure, so this is an engineering decision rather than a security one.

Why You Should Not Hash Passwords With SHA-512

There is a persistent intuition that a bigger digest means a stronger password hash. It does not, and understanding why clarifies the whole topic. The size of the output determines how hard it is to find a collision or invert the function mathematically. Password cracking does neither. An attacker guesses candidate passwords, hashes them, and compares. The only thing that matters is how many guesses per second they can afford, and on that measure SHA-512 is if anything worse than SHA-256, because on 64-bit hardware it runs faster.

Concretely, a single modern GPU handles SHA-512 at billions of hashes per second, and cloud instances with eight of them can be rented by the hour. Common password lists run to a few billion entries. The arithmetic is not encouraging.

Salt every password with at least 16 random bytes, unique per user, stored in the clear alongside the hash. This stops two users with the same password from sharing a digest and makes rainbow tables worthless. It is table stakes, not a solution, because it does not increase the cost of any individual guess.

The functions that do increase that cost are Argon2id, scrypt, and bcrypt. Argon2id is memory hard, meaning each evaluation demands a tunable block of RAM, and memory is exactly the resource that GPUs and ASICs cannot multiply cheaply. scrypt works on the same principle. bcrypt trades memory hardness for an extremely long track record and universal library support. Any of the three, correctly configured, turns a billion guesses per second into a few thousand.

There is one respectable exception. The $6$ variant of the Unix crypt function, used for shadow passwords on most Linux distributions, is SHA-512 based, but it applies thousands of rounds rather than one, which is a crude form of the same cost inflation. PBKDF2-HMAC-SHA512 does the same thing more explicitly and is FIPS approved. Neither is memory hard, so neither is a first choice, but both are far better than a bare SHA-512 call.

HMAC and SHA-512

HMAC wraps a hash function around a secret key so that the result authenticates a message rather than merely fingerprinting it. The construction, from RFC 2104, hashes the message twice: once with the key XORed against an inner pad and prepended, once more with the key XORed against an outer pad and prepended to that intermediate digest. Nesting the hash this way is what makes HMAC safe despite SHA-512 being vulnerable to length extension on its own.

A bare SHA-512 digest tells you a file was not corrupted in transit. HMAC-SHA512 tells you something considerably stronger: that the message is unmodified and that whoever produced the tag holds the shared secret. That combination of integrity and authenticity is what every API signing scheme is really buying.

HMAC-SHA512 appears as HS512 in the JWS and JWT specifications, as an option in AWS Signature Version 4 key derivation, in webhook signing for services that want a wide security margin, and in HKDF, the standard key derivation function used by TLS 1.3 and Signal. On 64-bit servers it is also the fastest HMAC in the SHA-2 family, so choosing it over HMAC-SHA256 can cost nothing at all.

Two practical warnings. Compare tags with a constant time function, never with plain string equality, because a normal comparison returns early and leaks how many bytes matched, which is enough to forge a tag one byte at a time. And note that HMAC keys longer than the block size, 1024 bits for SHA-512, are hashed down first, so an extremely long key buys no extra strength. The generator above supports HMAC mode if you want to compute one with your own key.

Comparing digest sizes side by side is often the quickest way to decide. The complete tools directory has SHA-256, SHA-1, and MD5 generators, a combined hash generator that shows several algorithms at once, and Base64 and hex utilities for when a 128 character digest is simply too long to pass around as text.