Cryptographic Architecture Last reviewed: October 2026 • 9 min read

Inside the Sponge Construction: How Keccak and SHA-3 Work

The sponge construction is an advanced cryptographic architecture that processes data by absorbing input blocks into a hidden internal state and squeezing out digest bits through repeated permutations. Unlike the Merkle-Damgård design used in MD5, SHA-1, and SHA-2, the sponge construction never exposes its full internal state, making length extension attacks mathematically impossible.

💡

In short

While SHA-2 hashes data like a conveyor belt where the final internal state is directly dumped as the output, the sponge construction maintains a 1,600-bit state split into bitrate (data being processed) and capacity (hidden security buffer). You absorb data in chunks, permute the internal state, and squeeze out any requested digest size—completely immune to length extension without needing an HMAC wrapper.

01. The Plain-Language Analogy: The Cellulose Kitchen Sponge

Imagine a real kitchen sponge soaked in a sealed glass box.

In the Absorbing phase, you inject drops of colored ink into the top surface of the sponge one teaspoon at a time. Between each drop, robotic arms knead, twist, and fold the sponge so the ink completely diffuses throughout its microscopic internal pores.

In the Squeezing phase, you gently press the sponge to extract whatever droplets of liquid you need for your canvas. Crucially, the deep core of the sponge (the capacity) is never squeezed dry. An onlooker who measures the extracted droplets only sees surface water; they can never deduce what liquid was absorbed previously or predict what drops will emerge next.

02. Step-by-Step Mechanics: Bitrate, Capacity & Permutation

Component

State Width b = r + c (1,600 Bits)

In SHA-3 (Keccak-f[1600]), the state is organized as a 5×5 array of 64-bit words (1,600 bits total). It is bifurcated into:
• Bitrate (r): The outer slice XORed with incoming message blocks. For SHA3-256, r = 1088 bits.
• Capacity (c): The hidden internal buffer that never interacts directly with input or output. For SHA3-256, c = 512 bits. Security level equals c / 2 = 256 bits.

Phase 1

The Absorbing Phase

The input message is padded using multi-rate padding 10*1 and partitioned into blocks of r bits. Each block is XORed into the bitrate portion of the state, followed by 24 rounds of the Keccak-f permutation (steps θ, ρ, π, χ, ι) to thoroughly scramble the entire 1,600-bit state.

Phase 2

The Squeezing Phase

The algorithm reads the first d bits from the bitrate portion to form the final hash. If the user requests an Extendable-Output Function (XOF) like SHAKE128/256 requiring more bits than r, the permutation runs again to generate additional pseudo-random output blocks indefinitely.

Node.js SHA-3 and SHAKE256 XOF Execution:

import crypto from 'node:crypto';

// 1. NIST SHA3-256 (FIPS 202) on empty string
const sha3Hash = crypto.createHash('sha3-256').update('').digest('hex');

console.log('Input: "" (Empty string)');
console.log('NIST SHA3-256:', sha3Hash);
// Expected: a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a

// Note: Ethereum Keccak-256 uses pre-NIST padding (0x01 instead of 0x06):
// Ethereum Keccak-256 of "": c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470

// 2. Extendable-Output Function (XOF) like SHAKE128 / SHAKE256
// Sponge allows squeezing any requested byte length:
const shake256 = crypto.createHash('shake256', { outputLength: 64 }).update('HashMama').digest('hex');
console.log('SHAKE256 (64 bytes / 512 bits squeezed):', shake256);

03. Worked Example: NIST SHA3-256 vs Ethereum Keccak-256

A common point of confusion is why Ethereum's "SHA3" produces different hashes than NIST SHA3-256. Below are the verified figures for an empty string input (""):

Input Data "" (Zero bytes / Empty string)

Ethereum Keccak-256 c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470

NIST SHA3-256 (FIPS 202) a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a

Domain Separation Byte Keccak uses 0x01 | NIST SHA-3 uses 0x06 (suffix 01)

Underlying Permutation Identical Keccak-f[1600] 24-round permutation

Ethereum adopted Keccak in 2014 before NIST finalized FIPS 202 in August 2015 with updated padding bits for domain separation. Both provide identical 256-bit security against all known attacks.

04. Common Misconceptions Corrected

✕ Misconception: "SHA-3 was created because SHA-2 is broken or vulnerable."

Reality: SHA-2 (SHA-256, SHA-512) remains completely secure and unbroken. NIST launched the SHA-3 competition in 2007 as a contingency plan because MD5 and SHA-1 both relied on the Merkle-Damgård construction. NIST wanted an alternative architectural paradigm (the sponge) in case Merkle-Damgård ever suffered a fatal flaw.

✕ Misconception: "You must use HMAC-SHA3 to authenticate messages securely."

Reality: In Merkle-Damgård hashes, H(secret || message) is insecure due to length extension attacks, necessitating HMAC. In the sponge construction, the capacity c is never published. Therefore, SHA3(secret || message) is mathematically immune to length extension. While NIST defined KMAC (SP 800-185), raw keyed hashing in SHA-3 is inherently safe.

✕ Misconception: "Ethereum smart contracts can verify NIST SHA3-256 natively."

Reality: The EVM opcode 0x20 executes original Keccak-256, not NIST SHA3-256. If you generate a NIST SHA3-256 hash off-chain and attempt to verify it with Solidity's keccak256(), the comparison will fail.