Library
Mastering Ethereum: Building Smart Contracts and DApps · 3 of 15
Mastering Ethereum: Building Smart Contracts and DApps
blockchain HIGH

Cryptography — Keys, Addresses & the One-Way Trap

Mastering Ethereum: Building Smart Contracts and DApps Andreas M. Antonopoulos & Gavin Wood
cryptography secp256k1 keccak256 addresses eip-55 private-keys

Key Principle

Ethereum uses no encryption — only digital signatures and hash functions (Chapter 4). All on-chain data is public, by necessity: every node must read every transaction to independently re-execute it and reach consensus. So cryptography here means proving knowledge of a secret without revealing it (signatures) and proving data authenticity (hashes) — never hiding data.

The chain of derivation is strictly one-way: private key → public key → address. A private key is "simply a number, picked at random" (Chapter 4); the public key is K = k · G (elliptic-curve scalar multiplication on secp256k1); the address is the last 20 bytes of Keccak-256(public key) (Chapter 4).

Why This Matters

Self-custody and irreversibility are rooted here: the private key is the account. Control of the key = control of the funds; reveal it and you've handed over the account; lose it and "the funds secured by it are lost forever" (Chapter 4). No authority can restore it.

Because the only thing standing between an attacker and your key is unguessability, randomness is the entire security model. The keyspace is up to slightly less than 2^256 (≈1.158×10^77, the order of Ethereum's curve) — near the ~10^80 atoms in the visible universe — so a truly random key is effectively unguessable. The guarantee evaporates the moment randomness is compromised.

Good Examples

  • secp256k1 public-key derivation, K = k · G. An Ethereum public key is a point (x, y) on the curve y² = x³ + 7 over a finite field of prime order p, derived by scalar-multiplying the fixed generator G by the private key k (Chapter 4). The reverse — "finding the discrete logarithm," recovering k from K — "is as difficult as trying all possible values of k... more time than this universe will allow for" (Chapter 4). There is no division on the curve. This is what lets you publish K (and the address) to receive funds while keeping k secret. Ethereum reuses Bitcoin's secp256k1 to inherit mature, battle-tested tooling — security-by-maturity (Chapter 4).
  • Address derivation (verbatim mechanism). Feed the public key into Keccak-256 without the 04 prefix; take the trailing 20 bytes (Chapter 4):
    k = f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315
K = 6e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444683bae07b83b5c38e5e...
Keccak256(K) = 2a5bc342ed616b5ba5732269001d3f1ef827552ae1114027bd3ecf1f086ba0f9
Last 20 bytes: 001d3f1ef827552ae1114027bd3ecf1f086ba0f9
0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9
  • EIP-55 capitalization checksum. Hex addresses are case-insensitive, so capitalization is invisible payload. Keccak-256 the lowercase address (no 0x); uppercase each alphabetic char iff the corresponding hash hex digit is ≥ 0x8. Supporting wallets validate with 99.986% accuracy; non-supporting wallets ignore it — fully backward-compatible (Chapter 4):
    0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9 -> 0x001d3F1ef827552Ae1114027BD3ECF1f086bA0F9

Counterpoints

  • Rolling your own RNG. Do NOT use a language's "simple" rand. A bad pseudo-RNG is worse than none, because its output is replicable — an attacker who reconstructs your seed regenerates your key and drains the account (Chapter 4). Use a CSPRNG seeded with sufficient entropy; entropy is "the first and most important step" (Chapter 4).
  • Confusing Keccak-256 with FIPS-202 "SHA-3". Ethereum uses the original Keccak that won NIST's 2007 competition, NOT the finalized SHA-3 — NIST altered the padding parameters afterward (Chapter 4). The difference is only padding, but outputs diverge, silently breaking address derivation, signatures, and verification. Verify with the empty-string vector: Keccak256("") = c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 vs SHA3("") = a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a (Chapter 4). Treat any "SHA-3" in Ethereum code as Keccak-256 until proven otherwise.
  • Including the 04 prefix when hashing the public key. It yields a wrong address; the 0x prefix is display-only hex encoding (Chapter 4). Raw addresses carry no built-in checksum — a regretted design that caused real fund losses, the direct cause for EIP-55 (Chapter 4).

Key Quotes

"Elliptic curve multiplication is a type of function that cryptographers call a 'one-way' function: it is easy to do in one direction (multiplication) and impossible to do in the reverse direction (division)." — Antonopoulos & Wood, Chapter 4

"Ethereum uses the exact same elliptic curve, called secp256k1, as Bitcoin. That makes it possible to reuse many of the elliptic curve libraries and tools from Bitcoin." — Antonopoulos & Wood, Chapter 4

"Resistance to hash collisions is particularly important for avoiding digital signature forgery in Ethereum." — Antonopoulos & Wood, Chapter 4

Rules of Thumb

  • Treat the private key as the account itself: never transmit, log, or store it unencrypted; loss is permanent.
  • Always generate keys from a CSPRNG over the full 2^256 keyspace — never a custom or "simple" RNG.
  • In Ethereum, "SHA-3" almost always means Keccak-256; confirm against the empty-string test vector before integrating any hash library.
  • Always display and accept addresses in EIP-55 mixed-case form to catch single-character typos before signing.
  • Don't roll your own elliptic-curve code; use mature libraries (OpenSSL EC_POINT_mul, libsecp256k1).

Related References