Keccak-256 vs SHA-256: Why Ethereum Uses a Different Hash Function Than Bitcoin

Every blockchain depends on cryptographic hash functions. Bitcoin uses SHA-256. Ethereum uses Keccak-256. Both are 256-bit hash functions that take arbitrary input and produce a fixed-length, deterministic, collision-resistant output. But they are built on fundamentally different architectures, were developed under different circumstances, and serve different roles in their respective ecosystems.

The relationship between Keccak-256 and SHA-3 adds an extra layer of confusion — Ethereum's documentation originally called its hash function "SHA-3," but it is technically the pre-standardization version of Keccak that differs from the final NIST SHA-3 standard. This article unpacks the history, explains the technical differences, and clarifies why it matters.

What Is a Cryptographic Hash Function?

A cryptographic hash function takes an input of any length and produces a fixed-size output (the hash or digest) with several critical properties. The function is deterministic — the same input always produces the same output. It is fast to compute. It is infeasible to reverse — given a hash, you cannot reconstruct the original input. It is collision-resistant — it is practically impossible to find two different inputs that produce the same hash. And a small change to the input produces a dramatically different output, a property called the avalanche effect.

These properties make hash functions essential to blockchain systems. They secure block headers, validate transactions, derive addresses, compute Merkle tree roots, and generate function selectors. The choice of which hash function to use is one of the most consequential design decisions in any blockchain protocol.

SHA-256: Bitcoin's Foundation

SHA-256 belongs to the SHA-2 family, designed by the National Security Agency (NSA) and published by NIST in 2001. SHA-2 is built on the Merkle-Damgard construction, the same structural approach used by its predecessors MD5 and SHA-1. The input is padded, split into fixed-size blocks, and processed through a compression function that iteratively updates an internal state.

SHA-256 produces a 256-bit (32-byte) digest. Bitcoin uses it extensively: the proof-of-work mining algorithm applies SHA-256 twice (double SHA-256) to block headers, transaction IDs are double-SHA-256 hashes of serialized transaction data, and Bitcoin addresses are derived through a combination of SHA-256 and RIPEMD-160.

SHA-256 has no known practical vulnerabilities. Despite theoretical attacks on reduced-round variants, the full 64-round SHA-256 remains secure. NIST has reaffirmed its confidence in SHA-2, stating that SHA-3 was developed as an alternative — not a replacement — in case a structural weakness is discovered in the Merkle-Damgard approach.

You can compute SHA-256 hashes with our SHA-256 hash generator.

Keccak: The SHA-3 Competition Winner

In 2007, NIST launched a public competition to develop a new hash function standard — SHA-3 — as insurance against potential future vulnerabilities in SHA-2. The competition attracted 64 submissions, which were narrowed through multiple rounds of public analysis. In October 2012, NIST selected Keccak (designed by Guido Bertoni, Joan Daemen, Michael Peeters, and Gilles Van Assche) as the winner.

Keccak is fundamentally different from SHA-2. Instead of the Merkle-Damgard construction, Keccak uses a sponge construction. The sponge works in two phases: an absorbing phase where input data is XORed into a portion of the internal state and mixed through a permutation function, and a squeezing phase where output bits are extracted from the state. The internal state is 1,600 bits wide (a 5-by-5 array of 64-bit words), far larger than SHA-256's 256-bit internal state.

The sponge construction gives Keccak a structural advantage: it is inherently resistant to length extension attacks, a class of vulnerability that affects SHA-256 and all Merkle-Damgard hashes. In a length extension attack, an attacker who knows the hash of a message (but not the message itself) can compute the hash of that message with additional data appended. This vulnerability requires workarounds in protocols that use SHA-256 — Bitcoin's double-SHA-256 is partly motivated by this concern.

Keccak-256 vs. SHA3-256: The Padding Difference

Here's where the confusion begins. After selecting Keccak as the competition winner in 2012, NIST spent three years finalizing the SHA-3 standard, publishing FIPS 202 in August 2015. During this process, NIST made a small but significant change: they modified the padding scheme.

Keccak as submitted to the competition uses a simple multi-rate padding (appending 10*1 to the input). The final NIST SHA-3 standard adds domain separation bits before this padding — specifically, it appends 01 for SHA-3 hash functions and 1111 for SHAKE extendable-output functions. This means that SHA3-256 and the original Keccak-256 produce different outputs for the same input, even though they use the same permutation function, the same sponge construction, and the same state size.

Ethereum's development began in 2013-2014, before NIST finalized SHA-3. Ethereum adopted Keccak-256 as submitted to the competition — the version without NIST's domain separation padding. When NIST published the final SHA-3 standard with the modified padding, Ethereum was already live and couldn't change its hash function without a hard fork.

Early Ethereum documentation and Solidity code referred to the function as sha3(), which was technically misleading. To clarify, Solidity 0.4.3 (released in 2016) renamed the function to keccak256(), with sha3() retained as a deprecated alias. Modern Ethereum documentation consistently uses "Keccak-256" to distinguish it from NIST's SHA3-256.

The practical implication: if you hash the same input with Keccak-256 and SHA3-256, you get different results. Tools and libraries must implement the correct variant. Our Keccak-256 hash generator uses Ethereum's Keccak-256 (pre-NIST padding), not SHA3-256.

Structural Comparison

The differences between SHA-256 and Keccak-256 go deeper than the output.

Construction. SHA-256 uses Merkle-Damgard; Keccak-256 uses the sponge construction. The Merkle-Damgard approach processes input blocks sequentially through a compression function. The sponge absorbs input into a wide state and squeezes output from it. The sponge's larger state provides a wider security margin.

Internal state size. SHA-256 maintains a 256-bit state. Keccak-256 maintains a 1,600-bit state, of which 512 bits are "capacity" (not directly affected by input) and 1,088 bits are "rate" (where input is absorbed). The large capacity provides the security guarantees.

Length extension resistance. SHA-256 is vulnerable to length extension attacks. Keccak-256 is inherently resistant because its capacity bits are never directly exposed in the output.

Permutation rounds. SHA-256 uses 64 rounds of its compression function. Keccak-256 uses 24 rounds of its permutation function (Keccak-f[1600]).

Software performance. On general-purpose x86-64 processors, SHA-256 is typically faster than Keccak-256 in pure software implementations. SHA-256 benefits from dedicated CPU instructions (Intel SHA Extensions, ARM SHA-2 instructions). Keccak is faster in hardware implementations and on platforms with SIMD support or dedicated Keccak instructions (ARMv8 SHA-3 extensions, IBM z/Architecture).

Flexibility. Keccak's sponge construction can produce output of any length (via SHAKE variants), function as a stream cipher, or serve as an authenticated encryption scheme. SHA-256 produces only a fixed 256-bit output.

Where Each Function Is Used in Blockchain

SHA-256 in Bitcoin: proof-of-work (double SHA-256 of block headers), transaction IDs, Merkle tree construction, address derivation (combined with RIPEMD-160), and BIP-39 mnemonic checksum calculation (as described in our article on BIP-39 mnemonic phrases).

Keccak-256 in Ethereum: address derivation (the last 20 bytes of the Keccak-256 hash of the public key), ABI function selectors (the first 4 bytes of the Keccak-256 hash of the function signature, as explained in our article on ABI encoding), EIP-55 address checksums (Keccak-256 of the lowercase hex address, as covered in our EIP-55 article), state trie node hashing, transaction and receipt hashing, event topic generation, and CREATE2 address computation.

Both in multi-chain contexts: some protocols use both. Solana uses SHA-256 for its proof-of-history chain and various on-chain operations. Polkadot uses Blake2b primarily but supports both SHA-256 and Keccak-256 for interoperability. Cross-chain bridges and interoperability protocols must handle both hash functions correctly.

Why Ethereum Chose Keccak

Vitalik Buterin and the Ethereum team chose Keccak-256 in 2013-2014 for several reasons. Keccak had just won the SHA-3 competition, representing the cutting edge of hash function design. Its sponge construction was considered more modern and robust than the Merkle-Damgard approach. The inherent resistance to length extension attacks simplified protocol design. And at the time, it appeared that Keccak would become the SHA-3 standard without modification — the padding change came later.

The decision was also influenced by a desire to differentiate from Bitcoin. Ethereum's designers wanted to avoid any dependency on SHA-256 mining hardware, which was dominated by Bitcoin ASICs. Using a different hash function ensured that Ethereum's original proof-of-work system (Ethash) couldn't be mined with Bitcoin-specific hardware. This concern became moot when Ethereum transitioned to proof-of-stake in September 2022 (The Merge), but it was a legitimate consideration during Ethereum's design phase.

Security Comparison

Both SHA-256 and Keccak-256 are considered fully secure as of today. Neither has any known practical attack. Their theoretical security levels are comparable: 128 bits of collision resistance and 256 bits of preimage resistance for both.

The broader security argument in favor of Keccak is structural diversity. SHA-256, SHA-1, and MD5 all share the Merkle-Damgard construction. If a fundamental flaw is discovered in this construction (beyond the known length extension issue), it could affect all three — and SHA-256's security margins would need to be reassessed. Keccak's sponge construction is structurally independent, providing an alternative that would remain unaffected by any Merkle-Damgard-specific vulnerability.

In practice, both functions are safe for their current uses. The choice between them is driven by ecosystem compatibility, performance requirements, and protocol design considerations rather than by security differences.

Using Our Hash Tools

Our Keccak-256 hash generator computes Ethereum-compatible Keccak-256 hashes. Use it to verify function selectors, compute address checksums, or validate transaction hashes. Our SHA-256 hash generator computes standard SHA-256 hashes compatible with Bitcoin and general-purpose cryptographic applications.

For working with the hex-encoded outputs of both functions, our hex-decimal converter translates between hexadecimal and decimal representations. And for understanding how these hashes connect to smart contract interactions, our ABI encoder demonstrates how function selectors (derived from Keccak-256) are used in transaction calldata.

The Bottom Line

SHA-256 and Keccak-256 are both excellent cryptographic hash functions with no known practical vulnerabilities. They differ structurally — Merkle-Damgard versus sponge construction — and each anchors a major blockchain ecosystem. The Keccak-256 vs. SHA3-256 distinction matters in practice: they produce different outputs due to NIST's padding modification, and Ethereum uses the original Keccak variant, not the final NIST standard. Understanding which hash function your tools and libraries implement is essential for correct blockchain development. When in doubt, verify with our Keccak-256 and SHA-256 generators.

References

Wikipedia — SHA-3 — History of the Keccak algorithm and the NIST SHA-3 standardization process.

Ethereum Stack Exchange — Which Hash Function Does Ethereum Use? — Community discussion clarifying the Keccak-256 vs SHA3-256 distinction.

Ethereum Classic — Why Ethereum Uses an Incorrect SHA3 — Historical explanation of Ethereum's Keccak adoption.

Shattered.io — SHA-256 vs SHA3-256 — Technical comparison of performance and security properties.

NIST FIPS 202 — SHA-3 Standard — The official SHA-3 specification including the padding modification.