EVM Threat Models

0x02-SHA256

10 min read

Precompile Summary

AddressNameGasInputOutputBehavior
0x02SHA25660 base + 12 per 32-byte word of input (rounded up)Arbitrary-length byte data32 bytes (SHA-256 digest)Computes the SHA-256 hash of the input per FIPS 180-4. Not the same algorithm as Ethereum’s native keccak256. Commonly used for Bitcoin-style verification, cross-chain proofs, and (at the protocol layer) EIP-4844 blob versioned hashes (kzg_to_versioned_hash uses SHA-256).

Threat Surface

The SHA256 precompile exposes a narrow but critical interface: arbitrary bytes in, fixed 32-byte digest out. Most risk is not “breaking SHA-256” in practice but misuse at the application layer: wrong hash function for the verification story (SHA-256 vs Keccak-256), unbounded input leading to griefing or resource skew, unsafe Merkle or tree constructions without domain separation, and consensus-critical use in blob hashing where any client divergence is a fork.

Bridges and SPV-style contracts depend on SHA-256 matching Bitcoin and other chains. Solidity developers routinely use keccak256 for Ethereum-native patterns (including many Merkle proofs in DeFi). Confusing the two yields subtle, often silent failures: proofs never verify, or verify the wrong statement. At the protocol level, EIP-4844 ties blob identity to SHA-256 inside versioned hash computation; implementation bugs or spec drift become network-splitting events, not mere application bugs.

Smart Contract Threats

T1: Hash Confusion Between SHA256 and Keccak256 (Medium)

Developers may call the SHA256 precompile where they intended Solidity’s keccak256 (or the reverse). The EVM’s “native” hash for many idioms is Keccak-256; Bitcoin SPV, many cross-chain specs, and some standards require SHA-256.

  • Wrong primitive for the spec. Internal “Ethereum-style” Merkle trees and signatures almost always assume Keccak-256; plugging in SHA-256 breaks compatibility with tooling, libraries, and off-chain indexers without an obvious revert.
  • Cross-chain and SPV mismatch. Bitcoin block headers and transaction Merkle paths use double SHA-256 and related conventions. Using Keccak where SHA-256 is required (or mis-encoding preimage formats) causes perpetual verification failure or acceptance of invalid data if paired with buggy custom checks.
  • Silent validation failure. Unlike a failed signature that reverts in a well-written verifier, a hash mismatch often appears as “proof invalid” or locked functionality, complicating incident response.

Why it matters: Hash confusion does not weaken SHA-256 cryptographically; it breaks the agreement between on-chain code and the system being verified. Bridges and light-client contracts are high-value targets where this class of error is easy to introduce and painful to debug.

T2: Gas Cost Manipulation via Large Inputs (Low)

Gas is linear in input size: 60 + 12 * ceil(len / 32) (per 32-byte word). The marginal cost per word is small relative to the cryptographic work users intuitively associate with “hashing.”

  • Unbounded caller-controlled input. If a contract hashes user-supplied data without a cap, an attacker can force large hashes, consuming a predictable chunk of the transaction gas limit.
  • Griefing and DoS shaping. Even without stealing funds, adversaries can make certain paths expensive or impossible within one transaction, affecting batching, auctions, or settlement flows that call SHA-256 on payloads they do not strictly control.
  • Economic asymmetry. Relayers or keepers pay gas; users may choose input sizes that maximize cost to the protocol under fixed fee rules.

Why it matters: This is rarely a direct “break SHA-256” issue but a resource and game-theory issue. Defensive bounds and clear trust boundaries on who supplies preimages keep behavior predictable.

T3: Hash Collision Assumptions (Informational)

SHA-256 remains strong for standard security parameters: there is no practical attack on full-round collision resistance relevant to on-chain 32-byte commitments today. Research on reduced-round variants (e.g., semi-free-start collisions on a 39-step variant where full SHA-256 uses 64 steps) illustrates that margins can be studied without invalidating deployed full SHA-256 for practical purposes.

  • Long-lived commitments. Contracts that encode decades-long or extremely high-value assumptions solely as “256-bit hash commitments” should account for cryptographic agility and parameter review over time—not because SHA-256 is broken today, but because threat models evolve.
  • Protocol design vs. primitive strength. Even a strong hash does not fix bad surrounding constructions (e.g., ambiguous preimage formats, replay across domains).

Why it matters: Auditors and architects should separate “SHA-256 is currently sound for collision resistance in practice” from “this Merkle tree / signing / bridge design is sound.” The latter depends on encoding, domain separation, and operational processes—not the hash label alone.

T4: Second Preimage Attacks on Merkle Trees (Medium)

Merkle trees that hash leaves and internal nodes with the same function and no domain separation can admit second preimage style attacks: an attacker may present a different tree shape or preimage that reproduces the same root under the verifier’s flawed assumptions. This is a classic issue when leaf data can be chosen to look like a “node” hash or when leaf and node hashing are indistinguishable.

  • Leaf vs. internal node ambiguity. If H(a) and H(left || right) use the same H without prefixes, adversaries can sometimes forge proofs that mix levels incorrectly.
  • Cross-ecosystem lessons. Bitcoin’s Merkle tree historically exhibited related pitfalls; CVE-2012-2459 concerned invalid block construction and Merkle tree handling that could affect implementations and assumptions around proof validation—not a break of SHA-256 itself, but a warning that tree rules matter as much as the hash.

Why it matters: Smart contracts that verify “Merkle proofs” must specify exact leaf serialization, ordering, depth handling, and domain separation (e.g., H(0x00 || leaf) vs H(0x01 || left || right)). SHA-256 does not automatically make an ad-hoc tree secure.

Protocol-Level Threats

P1: EIP-4844 Blob Versioned Hashes Depend on SHA-256 (High)

EIP-4844 defines blob commitment and verification using KZG; the versioned hash exposed to the execution layer uses SHA-256 (kzg_to_versioned_hash). If any consensus client implemented this step incorrectly (wrong standard, endianness, or input packing), blob validity would diverge across the network.

  • Consensus, not application scope. Bugs here are not “one dapp misconfigured”—they are chain-split or invalid-block classes of failures until fixed and coordinated.
  • Dependency on exact specification. Execution must match the EIP’s byte-level definition of the versioned hash, including the version byte and commitment bytes as specified.

P2: FIPS 180-4 Exactness and Cross-Client Parity (High)

All execution clients must implement SHA-256 for precompile 0x02 identically: padding, block processing, and output endianness per FIPS 180-4. Even small divergences (off-by-one padding, incorrect length encoding in a from-scratch implementation, platform-specific bugs) cause different digests for the same input, i.e., consensus failure.

  • Spec vs. library behavior. Most clients delegate to well-tested libraries (e.g., OpenSSL, libsecp256k1-adjacent crypto stacks, or audited SHA-256 implementations). Custom or partially optimized paths increase risk.
  • Testing burden. Differential testing against known vectors (including empty input and large messages within gas limits) is standard practice for this precompile class.

Edge Cases

CaseBehavior / notes
Empty inputReturns SHA-256 of the empty string: 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Input length ≥ 2^64 bitsUndefined in abstract FIPS length encoding; not reachable in the EVM in practice given gas limits and practical calldata/memory bounds.
Very large input (near block gas limit)Linear gas cost makes hashing large blobs feasible but expensive; contracts should still enforce business-logic limits to avoid griefing and failed transactions.
Identical digest for different preimages (practical)No known practical method for SHA-256 full rounds; do not rely on this for security—rely on correct protocols around the hash.

Real-World Exploits

Exploit 1: Bitcoin Merkle tree / block handling (CVE-2012-2459 context)

Root cause: Implementation and ecosystem handling of Merkle trees and block validity allowed problematic blocks to be constructed or propagated in ways that broke assumptions of some nodes and miners. The issue is not “SHA-256 was inverted”; it is that Merkle structure and validation rules must align with how proofs and blocks are interpreted.

Details: CVE-2012-2459 is associated with Bitcoin Core’s handling of malformed Merkle-related block data. Such incidents highlight that hash outputs alone do not define a secure system—the surrounding data structures and verification code must be correct and consistent.

Precompile’s role: On Ethereum, SHA-256 is the same primitive used in many Bitcoin-adjacent verification paths. Contracts replicating SPV or header checks must mirror Bitcoin’s double SHA-256, endianness, and Merkle conventions—not only call precompile 0x02 once with the wrong preimage layout.

Impact: For Bitcoin: consensus/partition and operational risk during the vulnerability window. For Ethereum contracts: analogous logic bugs in custom verifiers can strand funds, break bridges, or accept invalid proofs if implementations do not match the referenced chain’s rules.

References: CVE-2012-2459 (National Vulnerability Database / MITRE); Bitcoin Core release notes and advisories from the 2012 era for operational detail.

Attack Scenarios

Scenario A: Internal verification uses SHA-256 instead of Keccak-256

A contract stores keccak256(abi.encodePacked(a, b)) off-chain but on-chain verifies with SHA-256 over similar-looking packed bytes. Every honest proof fails; an attacker who controls a buggy alternate path might supply data that passes a custom check if the contract also mixes comparisons inconsistently.

// WRONG: Ethereum-native Merkle leaf often expects keccak256, not sha256
pragma solidity ^0.8.0;
 
contract BadLeafHash {
    function leafHash(address user, uint256 amount) public pure returns (bytes32) {
        // Many on-chain trees use keccak256 for leaves
        return sha256(abi.encodePacked(user, amount));
    }
}
// Typical expectation in Ethereum tooling (illustrative)
pragma solidity ^0.8.0;
 
contract ExpectedLeafHash {
    function leafHash(address user, uint256 amount) public pure returns (bytes32) {
        return keccak256(abi.encodePacked(user, amount));
    }
}

Scenario B: Merkle proof verification without domain separation

A verifier hashes keccak256(abi.encodePacked(a, b)) for both leaves and internal nodes with no prefix. An attacker chooses leaf encodings that collide with intermediate node formats accepted by the verifier’s parsing logic, breaking the intended uniqueness of paths (classic second-preimage style issues in poorly specified trees).

pragma solidity ^0.8.0;
 
contract UnsafeMerkle {
    function nodeHash(bytes32 a, bytes32 b) public pure returns (bytes32) {
        // No domain separation between leaf and internal node
        return sha256(abi.encodePacked(a, b));
    }
}
pragma solidity ^0.8.0;
 
contract SaferMerkle {
    bytes1 private constant LEAF_PREFIX = 0x00;
    bytes1 private constant NODE_PREFIX = 0x01;
 
    function leafHash(bytes memory data) public pure returns (bytes32) {
        return sha256(bytes.concat(LEAF_PREFIX, data));
    }
 
    function nodeHash(bytes32 left, bytes32 right) public pure returns (bytes32) {
        return sha256(bytes.concat(NODE_PREFIX, abi.encodePacked(left, right)));
    }
}

Mitigations

ThreatMitigationImplementation
T1 Hash confusionDocument and test the exact hash primitive and preimage layout; match off-chain tooling.Integration tests with known vectors; static naming (bitcoinMerkleRoot vs ethMerkleRoot); code review checklists for bridge modules.
T2 Large inputsEnforce maximum input length and caller trust boundaries.require(data.length <= MAX); separate admin-only paths; avoid hashing unbounded user blobs in single tx critical paths.
T3 Collision assumptionsUse modern primitives as specified; plan upgrades for long-horizon commitments where policy requires.Governance/time-locks; avoid sole reliance on one hash for multi-decade legal commitments without review.
T4 Merkle second preimageDomain-separated leaf and node hashing; explicit leaf encoding; fixed tree shape rules.Prefix bytes or distinct hash functions for leaves vs nodes; reject ambiguous depths; follow audited library patterns.
P1 / P2 ProtocolRely on spec-conformant client crypto; differential testing across clients.Client maintainers: use standard libraries, cross-client test vectors; monitor EIP-4844 updates.

Compiler/EIP-Based Protections

Solidity does not auto-select SHA-256 for keccak256(); the precompile is only used via sha256() in Yul/assembly or higher-level wrappers. EIP-4844 and execution-layer specs define blob versioned hashing—application devs do not reimplement it in contracts for standard blob paths, but must not roll custom “versioned hash” logic that diverges from the EIP when integrating low-level types. Compiler optimizations do not remove the need for correct preimage encoding in hand-written verifiers.

Severity Summary

Threat IDCategorySeverityLikelihoodReal-World Precedent
T1Smart contract / integrationMediumHigh (common developer error)Frequent bridge and indexing mismatches involving hash primitives
T2Smart contract / DoSLowMedium (where inputs unbounded)Resource griefing patterns on public contracts
T3Cryptographic assumptionInformationalLow (today)Ongoing academic analysis of reduced-round SHA-256
T4Smart contract / Merkle designMediumMedium (custom trees)Bitcoin Merkle-related issues (e.g., CVE-2012-2459 class lessons)
P1Protocol / EIP-4844HighLow (if clients correct)Any consensus hash mismatch is fork-class
P2Protocol / client parityHighLow (mature libraries)Historical chain forks often trace to implementation divergence
PrecompileRelationship
RIPEMD-160 (0x03)Often appears with SHA-256 in Bitcoin address derivation (RIPEMD160(SHA256(pubkey))); same integration care around preimage format and gas.
IDENTITY (0x04)No hashing; sometimes composed in data pipelines—does not substitute for domain separation or correct hash choice.
POINT_EVALUATION (0x0A)KZG point evaluation for EIP-4844; versioned hash computation uses SHA-256 at the protocol boundary—logical coupling to SHA-256 in blob workflows.

Graph View

Latest updates

Backlinks