How to generate a SHA-3 hash on Mac

A 64-character digest refuses to match the file it is supposed to describe, and you have downloaded that file twice now. Or a compliance profile names SHA3-256 where you expected SHA-256, or you are trying to reproduce what a library returned and getting a different answer by every route you try. The numbering invites you to read SHA-3 as a newer SHA-2, the way SHA-256 succeeded SHA-1. It is not that at all: SHA-3 is a different machine built from different parts, and the only thing the two families really share is the size of what comes out.

Your options on a Mac are narrower than they are for SHA-2, which is the first surprise. What works: the two rows under the SHA-3 group heading — SHA3-256 at 64 hexadecimal characters, SHA3-512 at 128 — in either the Text tool or Files, where clicking a row copies the whole digest rather than the shortened version on screen. For a single string you want to try right now, or a second opinion on a value you already have, the SHA3-256 generator and the SHA3-512 generator on this site hash text in the browser as you type it.

Three things account for nearly all the trouble: choosing between the two sizes, comparing a SHA3-256 against a SHA-256 because both are 64 characters, and the keccak256 in blockchain tooling, which is a third function again. That last one is where the afternoons go.

What a sponge does that a chain does not

SHA-2 works the way hash functions had worked since the 1980s. The message is cut into blocks, and each block is fed through a compression function along with a running state; when the blocks run out, the state is the digest. The state and the output are the same object, which is tidy until you want a digest that gives away nothing about the machinery behind it.

SHA-3 is a sponge. There is a single 1,600-bit state, and the message is absorbed into part of it a chunk at a time, each chunk mixed in by a permutation called Keccak-f that stirs the whole state. The state is split in two: a rate, which the message is allowed to touch, and a capacity, which it never is. Only the rate is ever read back out. SHA3-256 absorbs 136 bytes at a time and holds 512 bits of capacity back; SHA3-512 absorbs 72 bytes at a time and holds back 1,024 bits.

Two things follow from that split, and both are practical rather than theoretical. Because the capacity is never exposed, there is no internal state to recover from a digest and nothing to extend — the length-extension trick that SHA-512 is vulnerable to simply has no purchase. And because SHA3-512 absorbs in smaller bites, it runs the permutation roughly 1.9 times as often per byte as SHA3-256 does, so the wider digest genuinely costs more. That is the opposite of the situation in SHA-2, where SHA-512 usually outruns SHA-256 in software.

The history explains why both families are current rather than one replacing the other. Attacks published against SHA-1 in 2005 — a dozen years before anyone actually produced a collision — made everyone nervous about having one design underneath everything, so NIST ran an open competition from 2007 to 2012 for a function built on different foundations. Keccak won. It became FIPS 202 in 2015. SHA-2, meanwhile, has never been broken, so SHA-3 has spent a decade as a very well tested spare rather than a successor — the argument is laid out properly in SHA-2 vs SHA-3.

Produce a SHA-3 digest on your Mac

1. Find out which SHA-3 you need

   On its own, “SHA-3” is a family rather than an algorithm: FIPS 202 defines SHA3-224, SHA3-256, SHA3-384 and SHA3-512, plus the two SHAKE functions that emit as many bytes as you ask for. SHA3-256 and SHA3-512 are the two you will actually be handed, and they are the two Rocket Hash computes; the other two fixed sizes are rare in the wild, and a SHAKE is not a fixed-length digest at all. If a requirement really does name SHA3-384 or a SHAKE, it is outside the app's eight algorithms, and worth confirming with whoever wrote it — choosing among the eight covers what each one is actually for.

2. Type or drop the input

   The Text tool is free and hashes as you type; for a file, Files takes a drag-and-drop and reads the disk once, producing all eight digests from that pass. If you are chasing a value some library produced, hash the string itself rather than a file containing it, and watch the byte count — a text editor saves a trailing newline, which is one more byte and therefore a completely different digest.

3. Copy from the SHA-3 group, not the SHA-2 group

   The digests are grouped by family: SHA-2 first, then SHA-3, then CHECKSUM and LEGACY. This is the moment the mistake happens, because the SHA-256 row above and the SHA3-256 row below are the same length and look equally plausible on a clipboard. Read the colored chip at the start of the row, not the hex after it.

4. Label the digest when you pass it on

   Write SHA3-256 beside the value in the ticket, the README or the message. A bare 64-character string is ambiguous and no tool on the receiving end can resolve it from the length, because the length is identical either way. The same applies in reverse: if somebody sends you 64 characters with no label, ask which family it is before you conclude anything from a mismatch.

SHA3-256 is not SHA-256

The clearest way to see it is to hash the same three letters with both and put the results side by side. Here is the string abc — a published NIST test vector for the first two rows, and a value any Ethereum library will reproduce for the third:

Three functions, one input, 64 characters each, no relationship between them. If you have been comparing a SHA3-256 against a SHA-256 you were never going to get a match, no matter how many times you re-downloaded the file — and that is the failure mode worth recognizing early, because it looks exactly like corruption. Identifying which algorithm a checksum came from covers the other ambiguous lengths.

Keccak-256 is not SHA3-256 either

That third row is not a typo. When NIST standardized Keccak it made one change to the padding: SHA-3 appends two domain-separation bits to the message before the padding proper, which the competition submission did not do. Everything else — the permutation, the state size, the rate, the capacity — is untouched. Two bits, and the digests have nothing in common.

The practical rule is to read the name precisely. SHA3-256 with the digits attached means FIPS 202. keccak256, Keccak-256 or a library that predates 2015 usually means the submission. A document that just says “Keccak” and gives no version is worth querying before you build anything on it.

Choosing between SHA3-256 and SHA3-512

Usually you do not choose; the specification in front of you does, and matching it is the whole job. When the decision really is yours, SHA3-256 is the sensible default. Its 128 bits of collision resistance are already beyond any computation that will ever be performed, and it absorbs the message almost twice as fast as SHA3-512 does. Reach for SHA3-512 when a requirement says 512 bits, or when the thing you are feeding a digest into expects 64 bytes.

Speed rarely decides it. Expect SHA-3 to trail SHA-256 on a Mac, but by less than the folklore suggests: Apple Silicon carries instructions that accelerate the Keccak permutation as well as SHA-256, so neither family is left doing plain arithmetic. On a file the read is the bottleneck whichever row you take, which is why this is usually the wrong thing to optimize. Why hashing is slow covers the cases where the algorithm really is at fault, which are rare.

Nothing that ships with macOS computes SHA-3

Every digest tool Apple includes either predates FIPS 202 or ignores it: shasum is a SHA-1 and SHA-2 tool and answers Unrecognized algorithm to anything else, and the openssl in /usr/bin is a LibreSSL build with no SHA-3 digests in it. The Finder does not offer a checksum of any kind.

So on an unmodified Mac a SHA-3 comes from software you add, and that gap is the reason a SHA3-256 requirement usually arrives with no instructions attached. In the app the two digests sit under the SHA-3 group heading, in the free Text tool and in Files alike, and the Algorithm control in the Files toolbar puts whichever size you need on every row at once. The two calculators on this site cover a single string you want to spot-check in a hurry; bytes on disk are the Files tool's side of the line.

A SHA-3 for a file, and for a folder of them

The Text tool covers anything you can paste, which is most of what SHA-3 is used for in practice — a canonical string, a payload, a token. For bytes on disk, drop the file into Files and it becomes one row: the name, the folder it came from, the size and the digest. The Algorithm control in the toolbar decides which digest the rows show, and the disclosure chevron on a row opens every algorithm for that one file — the quickest way to see a SHA-256 and a SHA3-256 of the same bytes one above the other.

The file is read exactly once however many digests you asked for, so asking for both SHA-3 sizes costs one pass over the disk rather than two. Drop a folder in and every file inside becomes its own row, with the count and total size on the left of the status bar and progress on the right; memory stays flat at roughly 16 MB whether that is one file or a hundred thousand.

The export control writes the result out as a two-column list, one line per file. This is what it looks like for a folder holding an empty file and a file containing the three letters abc:

a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a  empty.txt
3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532  abc.txt

That is the shape every checksum list on the internet has, and here it is also the weakness: there is no column for the algorithm. A 64-character value in that file could be from either family, so put SHA3-256 in the filename and repeat it wherever the list goes. Exporting a checksum manifest covers the format properly.

Troubleshooting

My SHA3-256 will not match the published value

Check the family first, before the file. If the publisher's value came out of a tool that says “SHA-256” on the tin, you are comparing two different functions and the mismatch is meaningless. Once you are certain both sides are SHA3-256, the usual suspects apply: a partial download, a trailing newline, or the wrong file in a folder of similar ones.

The row shows only part of the digest

That is the display, not the value. Long digests are shortened in the middle with an ellipsis so a row stays one line, and a SHA3-512 at 128 characters is always shortened. Click the row — or the copy button on a file’s row — and the whole digest goes to the clipboard; what you must not do is read it off the screen and retype it, because the middle of it is not on the screen to read.

My digest does not match what my Ethereum library produced

Then one side is SHA3-256 and the other is the original Keccak-256. Libraries in that ecosystem use the pre-standard padding and usually name the function keccak256, occasionally sha3 for historical reasons, which is where the confusion comes from. Hash the three letters abc in both and compare against the table above — whichever row matches tells you which function you are actually calling.

I need SHA3-384 or a SHAKE output

Neither is among the eight algorithms in the app, and neither is on this site's calculators. Before you design around that, check the requirement: SHA3-256 and SHA3-512 are what a specification saying “SHA-3” almost always means, and a SHAKE is not a fixed-length digest at all — it emits as many bytes as the caller asks for, which makes it a different kind of thing to publish or compare. If SHA3-384 really is specified, say so early rather than shipping a SHA3-256 and hoping.

Should I move my existing checksums to SHA-3?

Not for security reasons. SHA-2 is unbroken, and a published SHA-256 is read by every tool your users already have, while a SHA3-256 will be met with a surprising number of people asking what it is. Switch when a standard or a customer requires it, or when you specifically want a second digest whose design shares nothing with the first.