Understanding SHAKE-128 hashing
SHAKE-128 (Secure Hash Algorithm Keccak Extendable-Output Function with 128-bit security) is an extendable-output function (XOF) standardized in NIST FIPS 202. Unlike traditional hash functions that produce a fixed-length digest, SHAKE-128 allows the user to specify the desired output length in bits, making it uniquely flexible for a wide range of cryptographic applications. It belongs to the SHA-3 family and is based on the Keccak sponge construction, which won the NIST SHA-3 competition in 2012.
As an XOF, SHAKE-128 can produce output of any desired length (up to 2128 bits theoretically) by squeezing the sponge state repeatedly. This makes it fundamentally different from fixed-output functions like SHA-256 or SHA3-256. The "128" in its name refers to its maximum security level: SHAKE-128 targets 128 bits of preimage resistance and approximately 64 bits of collision resistance (half the output length for collision attacks, as explained in detail by NIST Computer Security Resource Center).
Sponge construction
The Keccak sponge construction is the core innovation behind SHAKE-128. Unlike the Merkle-Damgård construction used by MD5, SHA-1, and the SHA-2 family, the sponge model operates in two distinct phases: absorbing and squeezing, as documented in the Keccak team's official specification.
- Absorb phase: Input data is XORed into the internal state (a 1600-bit array organized as a 5x5x64 matrix), then processed through a series of 24 Keccak-f permutation rounds. The permutation applies five computational steps: theta, rho, pi, chi, and iota.
- Squeeze phase: Once all input has been absorbed, the state is read out to produce the output. If more output bits are requested than the rate capacity allows, the state is permuted again and additional output is squeezed.
- Capacity vs. Rate trade-off: SHAKE-128 uses a 1600-bit state partitioned into rate (1344 bits) and capacity (256 bits). The capacity determines the security level, while the rate determines throughput. This design principle is explained in depth in the Keccak sponge function family documentation.
This sponge model inherently resists length extension attacks, a vulnerability present in many Merkle-Damgård based functions. The security properties of the Keccak sponge have been extensively analyzed by the cryptographic community, with results summarized in the NIST SHA-3 project page.
Output length control
- SHAKE-128 output can be generated at custom lengths, as long as the value is a multiple of 8 bits on this page.
- Short values (e.g., 16-64 bits) can be useful for examples, tags, and format tests.
- Longer values such as 256 or 512 bits are useful when comparing against fixed-length hash outputs.
- The requested output length changes the generated bytes, so record it whenever you compare results.
- Each output length produces a distinct digest for the same input, meaning
SHAKE-128("hello", 128)differs fromSHAKE-128("hello", 256).
One-way behavior
- SHAKE-128 is designed as a one-way function, so deriving the original input from the final hash should be computationally impractical.
- Small changes in the input produce very different outputs (avalanche effect), which makes it useful for integrity checking.
- The one-way property is formally defined as preimage resistance: given a target output y, finding any input x such that SHAKE-128(x) = y should require approximately 2128 operations.
Performance characteristics
- SHAKE-128 is designed to work well in both software and hardware settings, with efficient implementations available in C, Java, Python, and JavaScript.
- It is intended for modern cryptographic use and educational comparison with other hash families.
- The Keccak-f permutation used in SHAKE-128 is particularly well-suited for hardware acceleration, achieving high throughput in ASIC and FPGA implementations.
Security considerations
SHAKE-128 is regarded as a modern cryptographic XOF, but secure usage still depends on understanding the role of hashing, choosing enough output bits, and using audited implementations for critical systems.
- Collision resistance: SHAKE-128 provides min(128, n/2) bits of collision security where n is the output length in bits. For 256-bit output, this is 128 bits; for 64-bit output, it is only 32 bits.
- Preimage resistance: Given a hash, it should be impractical to recover an input that matches it. SHAKE-128 targets 128-bit preimage security regardless of output length.
- Second preimage resistance: Given one input, it should be impractical to find another input with the same hash. This is also bounded by 128 bits.
- Length extension resistance: SHAKE-128's sponge design inherently resists length extension attacks, unlike SHA-256 and other Merkle-Damgård functions.
Hashing is useful for integrity checks, but password storage and key management usually require dedicated algorithms such as bcrypt, Argon2, or PBKDF2 with additional safeguards.
SHAKE-128 vs SHA3-256: key differences
| Property | SHAKE-128 (XOF) | SHA3-256 (fixed hash) |
|---|---|---|
| Output length | Variable (user-selectable) | Fixed at 256 bits |
| Function type | Extendable-output function (XOF) | Fixed-output hash function |
| Security level | 128-bit preimage, min(128, n/2) collision | 128-bit collision, 256-bit preimage |
| Capacity | 256 bits | 512 bits |
| Rate (throughput) | 1344 bits | 1088 bits |
| Length extension resistance | Inherent (sponge design) | Inherent (sponge design) |
| Use case | Variable-length digests, key derivation, stream cipher | Fixed-digest integrity, digital signatures |
| Standard | NIST FIPS 202 | NIST FIPS 202 |
XOF output length guide
| Output bits | Output bytes | HEX characters | Base64 characters | Recommended use case |
|---|---|---|---|---|
| 16 | 2 | 4 | 4 | Short tags, format testing |
| 32 | 4 | 8 | 6 | CRC-like integrity checks |
| 64 | 8 | 16 | 12 | Lightweight fingerprinting |
| 128 | 16 | 32 | 24 | Minimum recommended for security |
| 256 | 32 | 64 | 44 | General-purpose hashing, comparable to SHA-256 |
| 512 | 64 | 128 | 88 | High-security applications, comparable to SHA-512 |
| 1024 | 128 | 256 | 172 | Key derivation, large XOF output |
Security levels by output bits
| Output bits (n) | Collision resistance (bits) | Preimage resistance (bits) | Second preimage (bits) | Security classification |
|---|---|---|---|---|
| 16 | 8 | 128 | 128 | Not secure: collisions can be found in about 28 operations |
| 32 | 16 | 128 | 128 | Not secure: collisions can be found in about 216 operations |
| 64 | 32 | 128 | 128 | Weak: 232 collision search is feasible |
| 128 | 64 | 128 | 128 | Moderate: 264 collision resistance |
| 256 | 128 | 128 | 128 | Standard: full security for SHAKE-128 |
| 512 | 128 | 128 | 128 | Standard: collision resistance capped at 128 bits |
| 1024+ | 128 | 128 | 128 | Standard: security does not increase beyond 128 bits |
As the table above illustrates, SHAKE-128's collision resistance is bounded by min(128, n/2). For outputs shorter than 256 bits, the collision security is less than 128 bits. NIST FIPS 202 Section 7.2 provides the formal security claims for all SHA-3 and SHAKE functions.
Applications of SHAKE-128
- SHAKE-128 can produce variable-length digests for protocol tests, format checks, and compatibility work.
- Integrity verification workflows can use SHAKE-128 when the expected output length is defined.
- It can be used as a deterministic byte expander in designs that explicitly call for SHAKE128, such as the Ed448 signature scheme in RFC 8032.
- It is useful for generating test vectors with short or long outputs from the same input.
- The sponge construction can be adapted for other cryptographic purposes beyond plain fixed-length hashing, including stream cipher modes and mask generation functions.
History of SHAKE-128
SHAKE-128 became part of the SHA-3 family through NIST FIPS 202. It represents the standardized extendable-output side of the Keccak design.
- 2012: Keccak is selected as the winner of the SHA-3 competition.
- 2015: NIST standardizes SHA-3 and the SHAKE functions in FIPS 202.
- After standardization: SHAKE-128 appears in research, protocols, test vectors, and flexible hashing workflows.
- Design diversity: SHAKE functions show how sponge-based XOFs differ from fixed-output hash functions.
- Long-term relevance: SHAKE-128 remains a useful tool when variable output length is part of the design.
Advanced configuration tips
- Input encoding discipline: Use UTF-8 for plain text, HEX for hexadecimal bytes, and Base64 only for properly encoded Base64 data.
- Output length choice: Start with 256 bits for general examples, then compare shorter and longer byte-aligned outputs as needed.
- Validation workflow: Test with short known samples first, compare with trusted libraries when exact matching matters, and record both encoding and output length.
Limitations and cautions
- Client-side processing: Everything runs in the browser.
- Encoding sensitivity: A wrong input format can produce an error or a different digest than expected.
- Browser dependency: The page assumes a modern browser with JavaScript enabled.
- Educational scope: This page is intended for learning, experiments, and quick format checks rather than full production deployment.
Final tips
- Start with UTF-8 input and 256 bit HEX output for the simplest first test.
- Use HEX and Base64 input modes only when your source value is already encoded that way.
- Double-check the exact output bit length before comparing against external examples.
- Use this page for education, experimentation, and quick browser verification.
- Use audited libraries and secure workflows for critical production needs.
Results are for educational and testing purposes only. Actual outputs depend on the exact bytes represented by the selected input encoding and output settings.