Rate and Capacity in the Sponge Construction

SHA-3 shares almost nothing with SHA-2 at the structural level. There is no chaining value, no block cipher and no feed-forward. There is one fixed permutation over a 1600-bit state, and both hashing and extendable output come from running it in one of two directions. The parameters that control security are the rate and the capacity, and they are not the same thing as the digest length. Getting that distinction wrong produces estimates of SHA3-512’s strength that are off by a factor of 2^256.

One state, two halves

The state is 1600 bits, arranged as a 5×5 array of 64-bit lanes. Keccak-f[1600] applies 24 rounds to that array, each round a composition of five step mappings: theta, rho, pi, chi, iota. The round count is fixed and does not depend on the input length or on the security level. This is a notable difference from SHA-2, where the number of compression calls grows with the message while the round function stays fixed.

The state is partitioned into two parts. The first r bits are the rate; the remaining c = 1600 - r bits are the capacity. Input is XORed into the rate portion only. The permutation is applied, and output is read from the rate portion only. Capacity bits are never written by the message and never read out as output.

Variant	Rate r	Capacity c	Digest	Collision target
SHA3-224	1152	448	224	112
SHA3-256	1088	512	256	128
SHA3-384	832	768	384	192
SHA3-512	576	1024	512	256
SHAKE128	1344	256	variable	128
SHAKE256	1088	512	variable	256

All figures are bits. The pattern is that c = 2 × the security level, and r takes whatever remains.

Absorb, then squeeze

Absorption processes the padded message in r-bit chunks. For each chunk, XOR it into the first r bits of the state, then apply the permutation. Padding is the pad10*1 rule: append a 1 bit, then zero or more 0 bits, then a final 1 bit, chosen so the result is a multiple of r. The two 1 bits are the reason the rule is written with a star; the number of intervening zeros varies with the message length.

Squeezing runs the permutation again and reads r bits per call, truncating at the digest length. For a digest shorter than the rate, one squeeze call suffices and the output is a prefix of the rate bits. For a digest longer than the rate, as with SHAKE, the permutation is applied between output blocks.

RATE = 136  # SHA3-256, in bytes; 1088 bits
CAPACITY_BYTES = 200 - RATE

def sponge(message: bytes, out_len: int) -> bytes:
    state = bytearray(200)  # 1600-bit state, all zero at the start
    padded = pad10_star1(message, RATE)
    for i in range(0, len(padded), RATE):
        for j in range(RATE):
            state[j] ^= padded[i + j]
        state = keccak_f1600(state)  # the permutation, treated as opaque here
    out = bytearray()
    while len(out) < out_len:
        out += state[:RATE]
        if len(out) < out_len:
            state = keccak_f1600(state)
    return bytes(out[:out_len])

Two details in that code carry the security argument. The initial state is all zeros, which is safe because the permutation is assumed to be indistinguishable from a random permutation, so no structure in the zero state survives one call. And the squeeze loop re-permutes before producing each additional block, so output blocks are not simply successive slices of one state.

Why capacity, not digest length, sets the bound

The security argument for a sponge is stated against the capacity. Collision resistance is c/2, preimage resistance is min(c/2, n) for digest length n, and the same c/2 figure governs the indifferentiability bound when the permutation is modelled as ideal. Truncating the output does not increase any of these; it can only reduce them.

This is why SHAKE128 has a 256-bit capacity and claims 128-bit collision resistance despite producing output of arbitrary length, while SHA3-512 has a 1024-bit capacity and claims 256 bits. A caller who wants 256-bit collision resistance from an extendable-output function needs SHAKE256, not SHAKE128 with a longer output. Lengthening the output of SHAKE128 gives more bytes and no more security, which is a mistake that shows up whenever a protocol specifies “SHAKE128 with 512-bit output” believing it has matched SHA3-512.

The capacity also explains the throughput numbers. Work per message byte is one permutation per rate bytes, so SHA3-256 processes 136 bytes per permutation and SHA3-512 processes 72. The permutation cost is identical in both cases, so SHA3-512 runs at roughly half the throughput of SHA3-256 on the same hardware. That ratio is a direct consequence of the security target, not an implementation artifact, and it is why short digests are preferred where the protocol allows them.

The absence of length extension

A sponge digest is a prefix of the rate bits after the final permutation. The capacity bits at that moment are unknown to the attacker, and they are part of the input to any subsequent permutation. To extend the message, an attacker would have to compute the next state, which requires the full 1600-bit state including the capacity. Knowing c bits of output is not enough when c ≥ 2 × the claimed security level, because reconstructing the state would require inverting the permutation on unknown bits.

That structural property removes the need for the HMAC-style double hashing that SHA-256 requires when a secret precedes the message. The design intent is documented in the sponge literature and is the reason KMAC is defined as a keyed sponge rather than as a construction over a plain hash. The corresponding problem in the iterated family is worked through in length extension and prefix-free encodings.

The property is conditional on using the sponge as specified. A construction that reads capacity bits as output, or that exposes intermediate state, gives the property up. Some designs do exactly that deliberately, and the security argument has to be restated for them.

Where the sponge is weak

Permutation-based hashing concentrates risk in one place. A distinguisher for Keccak-f[1600] that works with fewer than the design’s claimed margin would break every mode built on it at once: SHA-3, SHAKE, KMAC, keyak-derived schemes, and the various duplex modes. The SHA-2 family spreads risk differently, since a weakness in the compression function affects the hash but the underlying round structure is used in far fewer places. Cryptanalytic attention on Keccak since the 2007 submission has not produced a practical break, and the 24 rounds retain a substantial margin over the best published distinguishers, but the concentration is a real architectural difference.

The padding rule has an edge case worth knowing. pad10*1 requires at least two bits, so it cannot be applied to a rate of 1 bit, and the standard restricts rates accordingly. Implementations that accept arbitrary rates must reject the degenerate ones.

There is also a collision in the namespace that surprises people: the four fixed SHA-3 variants are not defined as SHAKE with a truncated output. SHA3-256 is not SHAKE256 truncated to 256 bits, because the two use different domain separation suffixes in their padding. SHA-3 appends the bits 01 before the pad10*1 sequence, while SHAKE appends 1111. The suffixes prevent a digest computed in one mode from being reinterpreted as a digest in another, which matters when a protocol accepts both a fixed hash and an extendable-output function over the same state. Implementations that compute SHA3-256 as a truncation of SHAKE256 produce values that are wrong in a way no test vector for the other function will catch.

Choosing a rate is choosing a trade

Because r + c = 1600 is fixed, every bit given to capacity is a bit taken from throughput. The standard’s choices set c to twice the security level, which is the minimum that keeps the generic attacks at the stated bound. A designer who wants a faster hash at a lower security level can raise r; SHAKE128 does exactly that, taking 1344 bits of rate and leaving 256 of capacity for 128-bit security. A designer who wants more margin can lower r and pay for it in speed.

The trade is not linear in the way it first appears. Permutation cost is roughly constant in r for a fixed state size, so halving the rate doubles the cost per message byte, while the security level changes by the square root of the capacity change. Going from 128-bit to 256-bit security costs a factor of two in throughput and a factor of two in capacity, which is a reasonable exchange; going from 256 to 384 costs another factor of about 1.4 in throughput for a much smaller marginal gain in any realistic threat model.

Sponges also do not parallelise within a single message. Each permutation depends on the entire previous state, so absorption is inherently sequential, exactly as the Merkle-Damgård fold is. The tree modes that recover parallelism do so by restructuring the message into leaves, which is a different construction rather than a faster sponge; parallel tree hashing covers that family.