Skip to main content
Hash Functions Intermediate

SHAKE128 and SHAKE256

Most hash functions give you a fixed-size output no matter what you ask for. SHAKE breaks that rule — it's a hash function you can ask for any amount of output from, built from the same Keccak sponge as SHA-3.

PL
Pashalis Laoutaris
August 4, 2026
5 min read

Interactive SHAKE Visualizer

🔐 SHAKE Extendable-Output Function

Real Keccak-f[1600] permutation — verified against a standard library implementation.
Enter text and click a button to start!
Phase:
Click Absorb & Squeeze to run the sponge construction.

SHAKE128 and SHAKE256

Introduction

SHAKE128 and SHAKE256 are part of the SHA-3 family, standardized by NIST alongside SHA3-224/256/384/512 in FIPS 202 (2015) — all built on the same underlying Keccak sponge construction that won the SHA-3 competition. But SHAKE (Secure Hash Algorithm KECCAK) is a different kind of primitive: it’s an Extendable-Output Function (XOF) — instead of a hash function’s fixed-size digest, SHAKE lets you request any amount of output, from a single byte to gigabytes, all derived deterministically from the same input.

Table of Contents

The Keccak Sponge Construction

Unlike SHA-2 (covered in the SHA-2 guide), which is built on the Merlin-Damgård construction, Keccak uses a fundamentally different design: a sponge. Picture a large internal state — 1600 bits, arranged as a 5×5 grid of 64-bit “lanes” — that gets repeatedly transformed by a fixed permutation function, Keccak-f[1600], consisting of 24 rounds each applying five simple steps (named θ, ρ, π, χ, ι in the specification) that mix, rotate, and non-linearly scramble the state.

Absorbing and Squeezing

The sponge operates in two phases:

  1. Absorbing: the input message (after padding) is XORed into the state, block by block (the “rate” portion of the state), running the Keccak-f[1600] permutation after each block — soaking up all the input data into the internal state.
  2. Squeezing: output bytes are read directly from the state’s rate portion. If more output is requested than the state currently holds, the permutation runs again to refresh the state before continuing to read — this is exactly what makes arbitrary-length output possible: just keep squeezing (and permuting) for as long as you need bytes.

Interactive Visualizer

The visualizer above runs a genuine, from-scratch Keccak-f[1600] permutation and sponge construction — no shortcuts — and produces output verified byte-for-byte against a standard cryptographic library implementation.

SHAKE128 vs. SHAKE256

The two variants differ in their internal rate (how many bytes get absorbed/squeezed per permutation call) and correspondingly their capacity (the portion of the 1600-bit state reserved purely for security margin, never directly exposed as output):

  • SHAKE128: rate = 1344 bits (168 bytes), capacity = 256 bits, offering 128 bits of security against both collision and preimage attacks.
  • SHAKE256: rate = 1088 bits (136 bytes), capacity = 512 bits, offering 256 bits of security.

Despite the naming echoing “128-bit” and “256-bit” like key sizes, both functions can produce output of any requested length — the numbers refer to their security level, not a fixed output size.

A Verified Example

Using the standard test input “abc”:

  • SHAKE128(“abc”, 16 bytes) = 5881092dd818bf5cf8a3ddb793fbcba7
  • SHAKE256(“abc”, 32 bytes) = 483366601360a8771c6863080cc4114d8db44530f8f1e1ee4f94ea37e78b5739

Requesting more or fewer output bytes for the same input simply extends or truncates this same deterministic stream — SHAKE128(“abc”, 32 bytes) starts with the exact same 16 bytes as SHAKE128(“abc”, 16 bytes), then continues.

Real-World Applications

  • CRYSTALS-Kyber and CRYSTALS-Dilithium: NIST’s standardized post-quantum algorithms use SHAKE internally for pseudorandom generation and hashing throughout their key generation, encryption, and signing operations.
  • Ethereum: uses a close variant of Keccak (technically pre-standardization Keccak-256, subtly different in padding from the final NIST SHA3-256) extensively for addresses and hashing throughout the protocol.
  • Deterministic random bit generation: SHAKE’s arbitrary-length output makes it a natural building block wherever a cryptographically secure, deterministic stream of pseudorandom bytes is needed from a fixed seed.
  • Key derivation: some modern protocols use SHAKE directly as a key-derivation primitive, taking advantage of its flexible output length.

FAQ

Is SHAKE the same as SHA-3?

They’re closely related — both are standardized in FIPS 202 and built on the identical Keccak-f[1600] permutation, but SHA-3 (SHA3-224/256/384/512) produces fixed-size digests like a traditional hash function, while SHAKE is explicitly designed for variable, extendable output.

Why would I want variable-length hash output?

Many protocols need pseudorandom bytes of a size that doesn’t match any standard hash digest length — deriving multiple keys of specific sizes, padding schemes, or streaming applications that need an open-ended supply of deterministic pseudorandom data, all without juggling multiple different hash functions.

Is SHAKE256 always “more secure” than SHAKE128?

For equivalent use cases, yes — SHAKE256 offers a higher security level (256 bits vs. 128 bits) at the cost of somewhat lower throughput (smaller rate, meaning more permutation calls for the same amount of data). Which to choose depends on the security margin your application actually needs.

What does “sponge construction” mean?

An architecture where data is “absorbed” into a large internal state through repeated permutation, then “squeezed” back out — the same conceptual metaphor as a physical sponge soaking up liquid and being squeezed to release it, applied to cryptographic state instead.

How is Keccak different from the SHA-2 family?

SHA-2 (used in SHA-256, SHA-512, etc.) is built on the older Merkle-Damgård construction with a fixed compression function processing one block at a time. Keccak’s sponge construction is structurally different, was specifically selected by NIST partly because it doesn’t share SHA-2’s construction (providing algorithmic diversity in case a future weakness were found in Merkle-Damgård-style designs), and natively supports variable-length output in a way SHA-2 doesn’t.

References

  1. NIST FIPS 202. “SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions.” Available at: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf

  2. Bertoni, G., Daemen, J., Peeters, M., and Van Assche, G. “The Keccak reference.” 2011 — the original Keccak design documentation from its creators.

  3. Wikipedia. “SHA-3.” Available at: https://en.wikipedia.org/wiki/SHA-3

  4. NIST SP 800-185. “SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash.” Extensions built on top of SHAKE.