Keccak-256
Technical • Cryptography • Hash Algorithms
the sponge-based hash algorithm powering Ethereum
Keccak-256 is the cryptographic hash function used throughout Ethereum and EVM-compatible blockchains. It produces a 256-bit (64-character hexadecimal) output from any input, just like SHA-256 — but its internal architecture is fundamentally different. While SHA-256 uses the Merkle–Damgård construction that processes data in sequential blocks, Keccak uses a sponge construction that absorbs input data and squeezes out the hash in a way that eliminates entire categories of vulnerability. The most significant advantage is immunity to length-extension attacks. SHA-256 requires double hashing to mitigate this weakness. Keccak does not — a single pass is sufficient for full security, which is why Ethereum never needed to implement double hashing in its protocol design. Keccak was selected as the SHA-3 standard by NIST in 2012 after a five-year public competition, but Ethereum’s implementation uses the original Keccak submission rather than the finalized NIST SHA-3 specification. The two produce different outputs from the same input due to a padding difference NIST introduced during standardization. This distinction matters — tools labeled “SHA-3” will not produce the same results as Ethereum’s Keccak-256. In Ethereum, Keccak-256 is everywhere. It generates wallet addresses from public keys. It computes function selectors that the EVM uses to route smart contract calls. It hashes storage slot locations for contract state. It produces transaction and receipt hashes. It secures the Merkle Patricia Trie that stores Ethereum’s entire world state. Every interaction with Ethereum — sending a transaction, calling a contract, verifying a balance — passes through Keccak-256 at some layer of the stack.
Use Case: When a user calls a function on an Ethereum smart contract, the EVM takes the first four bytes of the Keccak-256 hash of the function signature to identify which function to execute. If you call transfer(address,uint256), the EVM hashes that string with Keccak-256 and matches the first four bytes — routing execution without ever reading the function name as text.
Key Concepts:
- SHA-256 — Bitcoin’s Merkle–Damgård hash algorithm that Keccak was designed to succeed
- Cryptographic Hash — The broader category of one-way functions that Keccak-256 belongs to
- Collision Resistance — Security property providing 128 bits of collision resistance from Keccak’s 256-bit output
- Double Hash — The two-pass technique SHA-256 requires but Keccak’s sponge construction eliminates
- Sponge Construction — Keccak’s internal architecture that absorbs and squeezes data without Merkle–Damgård weaknesses
- EVM Function Selector — First four bytes of the Keccak-256 hash used to route smart contract calls
- Merkle Patricia Trie — Ethereum’s state storage structure secured by Keccak-256 at every node
- NIST SHA-3 vs Keccak — The padding difference that makes Ethereum’s Keccak-256 output differ from standardized SHA-3
- $ETH — The native asset of the network built entirely on Keccak-256 hashing
- Smart Contracts — Programs whose function routing and storage depend on Keccak-256 hashing
- ERC-20 — Token standard where every transfer and approval call is routed via Keccak-256 selectors
- Security Model — Framework where Keccak’s sponge construction provides the foundational hash assumption
Summary: Keccak-256 is to Ethereum what SHA-256 is to Bitcoin — the cryptographic foundation that every transaction, address, contract call, and state proof depends on. Its sponge construction solved the architectural weaknesses of Merkle–Damgård hashing, delivering single-pass security that Bitcoin’s protocol requires double hashing to achieve. Understanding Keccak-256 is understanding why Ethereum’s security model works differently from Bitcoin’s at the most fundamental level.
Where Ethereum Uses Keccak-256
the algorithm touches every layer of the EVM
Sponge vs Merkle–Damgård Construction
why Keccak eliminated an entire class of attacks
The Merkle–Damgård construction (used by SHA-256, MD5, SHA-1) processes data by chaining compression functions — the output of each block feeds into the next. This creates an internal state that, if known, allows an attacker to extend the hash without knowing the original input. The sponge construction processes data differently. It absorbs input into a large internal state, then squeezes output from that state. Critically, the internal state is larger than the output — Keccak’s state is 1600 bits while it only outputs 256. The remaining 1344 bits of internal state are never exposed, making length-extension attacks structurally impossible.
SHA-3 vs Ethereum’s Keccak-256
the padding difference that matters
When NIST standardized Keccak as SHA-3 in 2015, they added a two-bit suffix to the padding scheme — a domain separation flag that distinguishes SHA-3 from other sponge-based modes. Ethereum adopted Keccak before this change was finalized, which means Ethereum’s “Keccak-256” and NIST’s “SHA3-256” produce different outputs from the same input.
Practical Impact: If you use a library’s SHA3-256 function to compute an Ethereum address or verify a transaction hash, you will get the wrong result. Always verify that your tooling implements Keccak-256 specifically, not NIST SHA-3.
Keccak-256 Checklist
algorithm literacy — four-quadrant self-assessment
Whether your assets live on Ethereum or Bitcoin, the hash algorithms protecting them are only as strong as your key storage — secure with Ledger or Tangem.