SHA-3 and Keccak Explained: The Sponge Construction

SHA-3 is the newest member of the Secure Hash Algorithm family, and it is unlike everything that came before it. Where MD5, SHA-1, and SHA-2 all build on the Merkle–Damgård construction with a compression function, SHA-3 is built on a completely different idea called the sponge. Understanding that difference is the key to understanding why SHA-3 exists, why it is immune to length-extension attacks, and why it can stretch its output to any length you want. If you want the conceptual groundwork first, start with our pillar explainer on how hashing works, then come back here for the deep dive.

Why SHA-3 Exists: The NIST Competition

In 2004 and 2005, cryptographers found practical collision attacks against MD5 and serious weaknesses in SHA-1. Both of those functions, like SHA-2, share the Merkle–Damgård structure. NIST worried that a single breakthrough against that structure could compromise the entire deployed hashing ecosystem at once. So in 2007 it opened a public competition for a new standard, the same way AES had been chosen years earlier.

Sixty-four submissions arrived. After several rounds of public cryptanalysis, NIST announced Keccak as the winner in October 2012. Keccak was designed by Guido Bertoni, Joan Daemen (a co-designer of AES), Michaël Peeters, and Gilles Van Assche. NIST standardized it as FIPS 202 in August 2015 under the name SHA-3. Crucially, SHA-3 was never meant to replace SHA-2, which remains unbroken. It was chosen as a structurally different backup: if SHA-2 ever falls, SHA-3 is built on different math and should not fall the same way.

The Sponge Construction

The sponge is the heart of Keccak. Picture a large block of internal memory called the state, plus a fixed permutation f that scrambles that state reversibly. The state is conceptually divided into two parts:

• The rate r: the part the outside world interacts with.
• The capacity c: a hidden part that the message data never touches directly and that is never output.

Together r + c equals the total state width, which for SHA-3 is 1600 bits. The capacity is where the security lives, and we will see exactly why shortly.

A sponge works in two phases, just like a real sponge: it absorbs, then it squeezes.

Absorbing and Squeezing

In the absorbing phase, the padded message is chopped into blocks of r bits. Each block is XORed into the first r bits of the state (the rate), and then the whole 1600-bit state is run through the permutation f. Repeat for every block. The capacity portion is never XORed with message bits, but it gets stirred by f on every call, so the message indirectly influences it.

In the squeezing phase, you read the first r bits of the state as output. If you need more output than r bits, you apply f again and read another r bits, repeating until you have enough. For a fixed-length hash like SHA3-256, a single squeeze suffices.

absorb:
  state = 0^1600
  for each r-bit block P_i of padded message:
      state[0..r] ^= P_i
      state = Keccak-f(state)

squeeze:
  output = ""
  loop:
      output ||= state[0..r]
      if len(output) >= needed: break
      state = Keccak-f(state)
  return truncate(output, needed)

That is the entire framework. Everything specific to SHA-3 lives in two places: the choice of r and c, and the permutation f.

The 1600-Bit State as a 5×5×64 Cube

Keccak does not treat the state as a flat string. It organizes the 1600 bits as a three-dimensional array: a 5×5 grid of 64-bit lanes. That is 25 lanes × 64 bits = 1600 bits. The coordinates have names that the step mappings use:

• A lane is one 64-bit word at position (x, y).
• A row is the 5 lanes sharing the same y (5 bits across one z-slice).
• A column is the 5 lanes sharing the same x.
• A slice is a 5×5 cross-section at a fixed bit position z.

This geometry matters because the permutation's steps act along different axes — some on columns, some on rows, some rotating whole lanes. The permutation that scrambles this cube is called Keccak-f[1600], and it runs for 24 rounds.

The Five Step Mappings: θ ρ π χ ι

Each of the 24 rounds applies the same five steps in order. Four of them are linear (cheap and good at spreading bits around); only one is nonlinear (the source of cryptographic strength).

θ (theta) — diffusion across columns

Theta computes the parity (XOR) of each of the 320 columns, then XORs each bit with the parities of two neighboring columns (one adjacent column, and another offset by one bit position in z). The effect is fast, long-range diffusion: flipping one input bit quickly affects bits across the whole state. Without theta, columns would stay isolated.

ρ (rho) — lane rotations

Rho rotates the bits within each of the 25 lanes by a fixed, lane-specific amount (a rotation offset). This moves bits along the z-axis so that diffusion is not confined to a single slice. The rotation constants are fixed by the design and differ per lane.

π (pi) — lane permutation

Pi rearranges the positions of the lanes within the 5×5 grid according to a fixed permutation. Where rho moved bits inside lanes, pi moves whole lanes around the grid, breaking up the alignment between rows and columns so that theta and chi keep mixing fresh combinations of bits each round.

χ (chi) — the only nonlinearity

Chi is the single nonlinear step, and it operates on rows of 5 bits. Each bit is XORed with a function of the next two bits in its row: roughly a[x] ^= (NOT a[x+1]) AND a[x+2]. This AND gate is what makes Keccak resistant to linear and differential cryptanalysis. Every other step is linear; chi alone provides the algebraic complexity that prevents the permutation from being unwound.

ι (iota) — round constants

Iota XORs a round-specific constant into a single lane (lane (0,0)). The constants differ per round and break the symmetry that the other four steps share. Without iota, all 24 rounds would be identical and the permutation would have unwanted symmetries that an attacker could exploit.

Multi-Rate Padding: pad10*1

Before absorbing, the message must be padded to an exact multiple of r bits. Keccak uses a scheme called pad10*1: append a 1 bit, then as many 0 bits as needed, then a final 1 bit. The leading and trailing 1 bits guarantee the padding is reversible and that distinct messages never collide because of padding alone (for example, a message ending in zeros cannot be confused with a shorter one). Even when the message already fills a block, a full extra padding block is added so the final block is unambiguous.

SHA-3 Output Sizes and Their Capacities

FIPS 202 fixes the capacity at exactly twice the output length, which sets the security level. With a 1600-bit state, the rate is whatever is left over:

Larger output means larger capacity, which means a smaller rate — so SHA3-512 absorbs fewer message bits per permutation call and is therefore slower than SHA3-256. The capacity directly determines collision and preimage resistance: roughly c/2 bits of security against collisions.

SHAKE128 and SHAKE256: Extendable-Output Functions

FIPS 202 also defines two extendable-output functions (XOFs): SHAKE128 and SHAKE256. A XOF is a sponge whose squeezing phase you simply do not stop early — you can read as many output bits as you want, from a few bytes to gigabytes, all deterministically derived from the input.

The numbers 128 and 256 refer to the security level (capacity of 256 and 512 bits respectively), not a fixed output length. XOFs are extremely useful: deriving multiple keys from one seed, generating arbitrary-length masks (SHAKE256 is used inside several post-quantum schemes like ML-KEM and ML-DSA), stream-cipher-like keystreams, and deterministic random bit generation. For a comparison with other modern, fast designs, see our writeup on BLAKE2 and BLAKE3, which also offers a XOF mode.

Why Sponges Are Immune to Length Extension

This is the property that gives SHA-3 its strongest practical advantage over SHA-2. A length-extension attack works when the hash output is the full internal state, so an attacker who knows H(secret || message) can resume the computation and compute H(secret || message || padding || extra) without knowing the secret. SHA-2 (Merkle–Damgård) is vulnerable to exactly this.

In a sponge, the output is only the rate portion of the state. The capacity is never revealed. To continue the computation, an attacker would need the full 1600-bit state, but c of those bits (512 for SHA3-256) are secret and unrecoverable from the output. Length extension is therefore structurally impossible — no HMAC wrapper required. For the contrast with SHA-2's design and where these attacks bite, read SHA-256 explained.

Keccak vs SHA-3: The Domain-Separation Suffix

Here is a subtlety that trips up many developers. The Keccak submitted to the competition and the SHA-3 that NIST standardized are not byte-for-byte identical. During standardization, NIST added a domain-separation suffix to the padding: SHA-3 hashes append the bits 01 to the message before the pad10*1 padding, and SHAKE functions append 1111. This suffix cleanly separates the different functions so they can never produce the same output for the same input.

The practical consequence is Ethereum's keccak256. Ethereum adopted Keccak before FIPS 202 was finalized, so it uses the original Keccak padding without the 01 suffix. As a result, keccak256("") and SHA3-256("") produce completely different digests despite using the identical permutation. If you compute a hash for an Ethereum address or transaction and compare it to a "SHA3-256" tool, they will not match — and that is expected, not a bug.

Security Status in 2026

After more than a decade of intense public scrutiny, there are no significant attacks against full-round SHA-3 or SHAKE. The best published cryptanalysis reaches only a small number of reduced rounds, far short of the full 24, leaving a large security margin. SHA-3 remains a conservative, well-understood standard. Its value is not raw speed (in software it is often slower than SHA-256 and much slower than BLAKE3) but structural diversity: it fails differently than SHA-2, which is precisely why having both matters. For a head-to-head across generations, see MD5 vs SHA-256 vs SHA-3.

Conclusion

SHA-3 is a fresh start built on the elegant sponge construction: a 1600-bit state, a 24-round permutation made of θ, ρ, π, χ, and ι, and an absorb-then-squeeze flow that naturally yields fixed hashes (SHA3-224/256/384/512) and arbitrary-length XOFs (SHAKE128/256). Because the capacity never leaves the state, length extension simply cannot happen. The only common gotcha is the domain-separation suffix that distinguishes NIST SHA-3 from Ethereum's keccak256.

Want to see it in action? You can generate SHA-3 and SHAKE hashes in your browser with Hash Generator. Everything runs client-side via Rust compiled to WebAssembly — nothing you type is ever uploaded to a server. Try hashing the same input with SHA3-256 and SHAKE256 and watch the structure described here come to life.