SHA3-512 hash generator

Somebody has handed you 128 characters of hexadecimal, your SHA-512 of the same file disagrees with it, and the download is not what is wrong. A SHA3-512 runs to 128 characters of hexadecimal too, out of a function that shares nothing with SHA-512 but the width, and nothing in the string says which of the two you are holding. The other route to this page is a requirement that asks for 512 bits from outside the SHA-2 family, in which case this is the only box there is.

What changes when Keccak goes wide

Almost nothing, and that is the interesting part. SHA3-512 uses the identical 1600-bit state and the identical 24-round permutation as SHA3-256 — the sponge construction is the same, absorbing then squeezing, and generating a SHA-3 hash on a Mac walks through that machinery once rather than twice. What moves is the dividing line inside the state. The capacity, the hidden reserve that gives the function its security level, doubles from 512 bits to 1024. Since the state size is fixed, that has to come out of the rate: the amount of your message mixed in per permutation call falls from 136 bytes to 72.

So the wider digest costs you roughly 1.9 times as many permutation calls per megabyte of input. Every byte of your file gets the same 24 rounds applied to it, just in smaller mouthfuls. Per byte hashed, SHA3-512 is the most expensive of the eight algorithms — invisible on a string of the length this page is for, and noticeable only on the multi-gigabyte files an app reads off a disk.

The same rule fixes the other two widths, because the capacity is always twice the output: SHA3-384 takes 104 bytes of your message per permutation call and SHA3-224 takes 144. Nothing about the permutation itself changes between them, which is why an implementation that gets one width right almost always gets all four right, and why the only part you have to get right yourself is which width the specification in front of you asked for.

That is worth holding next to the SHA-2 family, where the same move goes the other way. SHA-512 is typically quicker per byte than SHA-256, because going wide there meant rebuilding the arithmetic in 64-bit words and swallowing 128 bytes a block instead of 64. In SHA-3, the machine never changes size, so a wider output has nowhere to go but smaller bites. Bigger number, more work — which is what most people expect of SHA-2 and do not get.

Telling two 128-character digests apart

SHA-512 and SHA3-512 both produce 512 bits, written as 128 hexadecimal characters, drawn from the same sixteen symbols, with no structure, no prefix and no checksum digit to give the game away. Nothing in the string tells you which function made it, and the two are entirely unrelated values. BLAKE2b and Whirlpool produce 128 characters as well, so even “one of those two” is an assumption.

There are only three honest ways out, and the first is the one to insist on:

• Label it at the source. Write SHA3-512 next to the value, or put it in a file named for the algorithm. Every minute spent on the other two routes is a minute somebody saved by not typing eight characters.
• Test it against the file. If you have the file the digest describes, compute both and see which one lands. This is the fastest answer in practice and the reason a tool that produces every algorithm from one read is useful — you stop guessing in advance.
• Test it against something you know. If the input is something you can reproduce — an empty file, a known string — the first few characters identify the function immediately.

Length is a weaker clue than people assume generally, not just here — reading an algorithm off a checksum sets out where it works and where it runs out. And when both values are 128 characters and they still disagree, mismatched algorithms should be your first suspicion, well before corruption.

When 512 bits of Keccak is the actual requirement

This is a specified algorithm far more often than a chosen one. The cases where it is genuinely the right box:

• A document that names it. Compliance profiles and protocol specs written since FIPS 202 sometimes require a 256-bit security level and a non-SHA-2 function in the same breath. SHA3-512 is the answer to that sentence.
• Deliberate family diversity at the top margin. If your threat model includes “a structural break in SHA-2 is found in my lifetime”, recording a second digest from an unrelated construction is cheap insurance, and at 512 bits it is the widest insurance available.
• Archives meant to outlive their tooling. Preservation manifests are written once and consulted in thirty years. The extra margin costs disk space measured in bytes per file.
• Keyed hashing at this width. SHA-3 needs no HMAC wrapper around it, and KMAC256 — specified in SP 800-185 on the same permutation — is the keyed function to reach for when the output has to be 512 bits.

What 512 bits actually buys: 2²⁵⁶ attempts to find a collision, against 2⁵¹² to reverse a specific digest. An attacker who needs any two inputs that agree, rather than one particular input, gets the birthday discount, which is why the collision figure is the one worth quoting. It is identical to SHA-512's, so picking between the two is a question of which family you want, not of strength. And quantum computing is not the reason to move — the best known quantum result against a hash function reduces a preimage search to roughly the square root of the work, and does nothing of practical use against collisions, which is why nobody is being told to abandon 256-bit digests. SHA-2 versus SHA-3 takes that apart properly.

Where a SHA3-512 of a real file comes from

Nothing macOS ships computes SHA-3 at any width, which is part of why a SHA3-512 tends to arrive from somewhere else and then sit in a ticket unverified. The box above will settle a string on the spot — paste the input a value is supposed to describe, read the 128 characters, compare — and nothing leaves the tab while it does, because there is no upload endpoint to call. A file is past what any page here can do — reading bytes off your own disk is an app’s job, not a web page’s — and with SHA3-512 the choice of machinery matters more than with any of the others, because it is the most expensive of the eight per byte and a long run is one you want to watch rather than guess at.

Rocket Hash reads a file once and produces all eight digests out of that single pass, which turns the “compute both and see which one lands” test above into one operation instead of two trips through the same gigabytes: drop the file into the Files tool, open the chevron on its row, and the SHA-512 and the SHA3-512 sit one above the other with their names attached, so whichever of them matches the value you were given identifies itself. Live throughput and an estimated time remaining run while it works — the two numbers you want most on the slowest algorithm here — memory stays flat at roughly 16 MB however large the file is, and a long run can be paused mid-file and resumed from the exact byte rather than started again.

Text hashing is free. The folder side — a queue of a hundred thousand files, the pause, the shasum-compatible manifest at the end — is one unlock, and the Verify tool, which turns a pasted checksum and a dropped file into a green seal and a sentence, is a separate one. Which algorithm to use is still worth a minute first, because for most jobs the answer is SHA-256.

Frequently asked questions

How do I tell whether a 128-character hash is SHA-512 or SHA3-512?

Not by looking at it — both are 512 bits of hexadecimal with no distinguishing structure, and BLAKE2b-512 and Whirlpool are the same length again. If you have the file, compute both and see which of them lands on the value you were given. If you can reproduce the input, the opening characters identify the function: the digest of an empty input begins cf83e135… for SHA-512 and a69f73cc… for SHA3-512. Otherwise you have to ask whoever published it.

Why is SHA3-512 slower than SHA3-256?

Because a wider SHA-3 digest reserves more of the internal state and therefore takes smaller bites of your data. SHA3-256 mixes in 136 bytes per run of the permutation; SHA3-512 mixes in 72. Both run the same 24 rounds each time, so the wider function needs roughly 1.9 times as many runs to get through the same file. In the SHA-2 family the relationship is reversed, which is the source of most of the confusion.

Is SHA3-512 more secure than SHA-512?

Not in any measurable sense today. Both give 512-bit outputs, 256 bits of collision resistance, and neither has ever been dented. The differences are structural: SHA3-512 is a sponge over a permutation rather than a compression chain, so it is immune to length extension, and a future attack on the SHA-2 design would not automatically apply to it. That is insurance, not extra strength.

Can I use SHA3-512 where a system expects SHA-512?

No. They are different functions that happen to produce the same number of characters, so the value will be accepted as well-formed and then fail every comparison. Whenever a digest crosses a boundary between two systems, both sides have to name the same algorithm — length agreement is not agreement.

Is SHA3-512 a sensible choice for checksumming large files?

It works perfectly and it is the slowest way to do it. Nothing published on a download page uses SHA3-512, so you will not be comparing against anybody, and per byte it costs more than any other common digest. If you want a SHA-3 digest in your own manifests, SHA3-256 gives you the same family at roughly half the work, and for files generally SHA-256 remains what the rest of the world will recognize.

What is the difference between SHA3-512 and SHAKE256?

SHAKE256 is an extendable-output function: you ask it for as many bytes as you want, rather than a fixed 64. Both are built on the same Keccak permutation, but they use different domain-separation bytes and different rates, so asking SHAKE256 for 64 bytes does not give you the SHA3-512 digest of the same input. They are not interchangeable, even at matching lengths.