Keccak-256 is a cryptographic hash function and the specific variant of the Keccak family used by Ethereum for its core cryptographic operations. Keccak was selected as the winner of the NIST SHA-3 competition on October 2, 2012, though Ethereum uses the original Keccak-256 submission rather than the final NIST-standardized SHA-3 (which differs in padding). In Ethereum, Keccak-256 is ubiquitous: it hashes transaction data to create transaction IDs, derives wallet addresses from public keys (the last 20 bytes of Keccak-256 of the public key), powers the Merkle-Patricia trie structure for state storage, and is used extensively in Solidity smart contracts via the keccak256() built-in function. Keccak-256 produces a 256-bit (32-byte, 64 hexadecimal character) output from inputs of any size, with all the standard cryptographic hash properties: deterministic, one-way, avalanche effect, and collision resistance.
Origin & History
| Date | Event |
|---|---|
| Nov 2007 | NIST announces SHA-3 competition; seeks next-generation hash standard |
| Oct 2008 | Keccak (by Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche) submitted before the October 31 deadline |
| Jul 2009 | Keccak advances to second round among 14 selected candidates |
| Dec 2010 | Keccak advances to the third and final round of the competition |
| Oct 2, 2012 | NIST selects Keccak as SHA-3 winner |
| Nov 2013 | Vitalik Buterin publishes the Ethereum whitepaper incorporating Keccak-256 (pre-standardization version) |
| Jul 2015 | Ethereum mainnet launches; Keccak-256 becomes foundation of all Ethereum cryptography |
| Aug 2015 | NIST finalizes SHA-3 (FIPS 202) with a padding change; Ethereum’s Keccak-256 is not identical to NIST SHA-3-256 |
| 2023 and beyond | Keccak-256 remains unbroken; standard across all EVM-compatible chains |
How It Works
Keccak-256 uses a sponge construction rather than the Merkle-Damgård design used by SHA-256. The process works as follows:
- The input message of any length is padded to a multiple of the block size (1088 bits for Keccak-256)
- During the absorbing phase, the padded input is XORed with the internal 1600-bit state, then the Keccak-f[1600] permutation is applied repeatedly
- During the squeezing phase, 256 bits are extracted from the state to produce the final hash output
Example (Ethereum Address Derivation):
A 256-bit random private key is multiplied by the secp256k1 elliptic curve generator point to produce a 512-bit public key. Keccak-256 is applied to that public key. The last 160 bits (20 bytes) are taken, yielding the Ethereum address (for example, 0x742d35Cc6634C0532925a3b844Bc454e4438f44e).
Comparison Table:
| Property | Keccak-256 | SHA-256 (Bitcoin) | MD5 (deprecated) |
|---|---|---|---|
| Output size | 256 bits | 256 bits | 128 bits |
| Construction | Sponge | Merkle-Damgård | Merkle-Damgård |
| Security status | Secure | Secure | Broken |
| Used by | Ethereum, EVM chains | Bitcoin, many others | Legacy only |
| NIST SHA-3 | Close (not identical) | SHA-2 family | Unrelated |
In Simple Terms
Ethereum’s fingerprint machine: Every piece of data in Ethereum — transactions, blocks, addresses, state — is identified by its Keccak-256 hash. It is the fundamental identifier for everything on the network.
Address generation: Your Ethereum wallet address comes from Keccak-256. It hashes your public key and takes the last 20 bytes. Losing your private key means the address still exists on-chain but is permanently inaccessible.
Sponge design: Keccak uses a sponge approach — absorb input data, squeeze out hash output — which is different from Bitcoin’s SHA-256. The sponge design is immune to length extension attacks that affect Merkle-Damgård constructions like SHA-256.
Smart contract use: In Solidity, keccak256(abi.encodePacked(data)) is the standard way to hash data within smart contracts, used for access control, data verification, and unique identifier generation.
Not SHA-3: Despite being selected as SHA-3’s basis, Ethereum uses the original Keccak submission, not the final NIST standard. They differ in padding and produce different outputs for the same input. Always use Keccak-256 specifically for Ethereum applications.
Real-World Examples
| Scenario | Implementation | Outcome |
|---|---|---|
| Address derivation | Keccak-256(public key) takes last 20 bytes to produce Ethereum address | Every Ethereum address is derived this way |
| Transaction ID | Keccak-256(signed transaction bytes) produces 32-byte TXID | Look up any transaction on Etherscan via its Keccak-256 hash |
| Smart contract access | require(keccak256(input) == storedHash) in Solidity | Simple password/commitment verification without storing plaintext |
| ERC-20 function selector | Keccak-256(“transfer(address,uint256)”)[0:4] = 0xa9059cbb | Standard function identifiers in ABI encoding |
| Merkle-Patricia trie | State root = Keccak-256 of entire Ethereum state tree | Ethereum’s single-line summary of all balances and contract states |
Advantages
| Advantage | Description |
|---|---|
| Security | No known collisions or preimage attacks; battle-tested since 2012 |
| Flexible input | Handles any input size (empty string to gigabytes) with uniform output |
| Efficient | GPU-friendly design; computationally efficient for blockchain operations |
| EVM native | Built into Ethereum protocol as an opcode (SHA3); extremely cheap in gas |
| Sponge properties | Novel construction; immune to length extension attacks that affect SHA-256 |
Disadvantages & Risks
| Disadvantage | Description |
|---|---|
| Not standard SHA-3 | Ethereum’s Keccak-256 differs from NIST SHA-3-256; a common source of implementation confusion |
| Quantum risk | All current hash functions face theoretical quantum vulnerability long-term |
| Implementation bugs | Using wrong padding (SHA-3 vs Keccak) creates silent security bugs in code |
| Single algorithm dependency | Ethereum’s security model assumes Keccak-256 remains unbroken |
| Gas cost | Although cheap, keccak256() in tight loops can add meaningful gas costs |
Risk Management Tips:
- In Ethereum smart contract development, always use keccak256() rather than sha3() from some libraries, which may refer to NIST SHA-3 and produce different results
- When verifying Ethereum data off-chain, use a library that implements Keccak-256 specifically — ethers.js and web3.js both provide the correct implementation
- Hash preimages (inputs) should be unique and unguessable for security-sensitive commitments
FAQ
Q: What is the difference between Keccak-256 and SHA-3?
A: NIST changed the padding parameters when finalizing SHA-3 in August 2015. Ethereum uses the original Keccak-256 submission from the competition. They produce different outputs for the same input. Always use Keccak-256 specifically for Ethereum applications.
Q: How is my Ethereum address created from Keccak-256?
A: Generate a random 256-bit private key, multiply by the secp256k1 elliptic curve generator point to get a 512-bit public key, apply Keccak-256, take the last 160 bits (20 bytes), and prepend 0x to get your Ethereum address.
Q: Is Keccak-256 safe for passwords?
A: Not for password storage. Like SHA-256, Keccak-256 is very fast, making it vulnerable to brute force and rainbow table attacks for passwords. Use bcrypt, Argon2, or scrypt for passwords instead.
Q: What is the gas cost of keccak256() in Solidity?
A: 30 gas plus 6 gas per 32-byte word of input. Very cheap for small inputs; can add up in loops processing many small pieces of data.
Q: Does Bitcoin use Keccak-256?
A: No. Bitcoin uses SHA-256 (twice, known as SHA-256d) for proof of work and block hashing, and RIPEMD-160 combined with SHA-256 for address generation. Keccak-256 is specific to Ethereum and EVM-compatible chains.
Related Terms
Hashing, SHA-256, Ethereum (ETH), Smart Contract, Wallet Address, Merkle Tree, Cryptography
UPay Tip: If you are building Ethereum smart contracts or off-chain Ethereum tools, always test your Keccak-256 implementation against known test vectors. For example, keccak256(“”) should equal 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. This instantly catches the common SHA-3 vs Keccak-256 padding confusion before it causes a bug in production.
Disclaimer: This content is for educational purposes only and does not constitute financial or investment advice. Cryptocurrency investments are subject to market risks.
