Cryptography for Blockchain

What Is Cryptography?

Cryptography is the science of securing information and communication through mathematical techniques. In blockchain, it is not a feature layered on top — it is the foundation. Every address, every signature, every block, and every proof is a cryptographic object. Without cryptography, trustless systems cannot exist.

The word comes from the Greek kryptos (hidden) and graphia (writing). For most of history, cryptography meant substitution ciphers and secret codes — techniques that required sharing a secret key in advance. The revolution of modern cryptography, beginning in the 1970s, was the discovery that two parties who have never met can establish a shared secret over a public channel, and that knowledge can be proven without being revealed. Both of these ideas are now embedded in the infrastructure of every blockchain.

Bitcoin's 2008 whitepaper runs to nine pages. It describes a peer-to-peer electronic cash system, but the mechanism it relies on — digital signatures, hash functions, and Merkle trees — had already been developed over decades of academic cryptography research. Satoshi Nakamoto did not invent new cryptography; he assembled existing primitives into a system where they made trust unnecessary between strangers.

Modern blockchain cryptography falls into four categories: hash functions, which create tamper-evident fingerprints; asymmetric (public-key) cryptography, which allows private ownership and digital signatures; commitment schemes, which allow a party to bind themselves to a value without revealing it; andzero-knowledge proofs, which allow knowledge to be proven without disclosure. This guide covers the first three in depth — the bedrock that every blockchain user interacts with, knowingly or not, on every transaction.

Hash Functions

A cryptographic hash function takes an input of any size and produces a fixed-size output — the hash, digest, or fingerprint — such that it is computationally infeasible to reverse the operation or find two inputs that produce the same output. Hash functions are the most widely-used primitive in blockchain: they secure blocks, addresses, commitments, and data structures.

The formal security properties of a cryptographic hash function are:

Pre-image resistance: given a hash output h, it is computationally infeasible to find any input m such thatH(m) = h. This is the "one-way" property — you can compute a fingerprint but you cannot reverse it to recover the original data.

Second pre-image resistance: given an input m₁, it is computationally infeasible to find a different input m₂ such thatH(m₁) = H(m₂). This prevents an attacker from substituting a malicious document that happens to have the same fingerprint as a legitimate one.

Collision resistance: it is computationally infeasible to find any pair of inputs m₁ ≠ m₂ such that H(m₁) = H(m₂). Collision resistance is stronger than second pre-image resistance — the attacker is free to choose both inputs. The birthday paradox means that finding a collision requires only roughly 2^(n/2) operations for an n-bit hash — SHA-256 has ~2^128 collision resistance, not 2^256.

Avalanche effect: a single bit change in the input changes approximately half the output bits, unpredictably. This means similar inputs produce completely different outputs — you cannot infer anything about the input from comparing outputs.

Bitcoin uses SHA-256 in three ways: the proof-of-work puzzle requires miners to find a nonce such that SHA-256(SHA-256(block_header)) is below a target threshold; transaction IDs are double-SHA-256 hashes of the raw transaction; and addresses are derived via RIPEMD-160(SHA-256(public_key)), shortening the output to 160 bits while maintaining pre-image resistance.

Ethereum uses Keccak-256 everywhere. Ethereum addresses are the last 20 bytes of Keccak-256(public_key). Smart contract storage slots are Keccak-256 hashes of the key and slot index. Event signatures (the topic0 used to filter logs) are Keccak-256 hashes of the function signature string. The block hash is the Keccak-256 of the RLP-encoded block header. Solidity's built-in keccak256()exposes this directly to smart contract developers.

Public-Key Cryptography

Public-key cryptography (asymmetric cryptography) solved a problem that seemed impossible: how can two parties communicate securely without ever sharing a secret in advance? The insight is to use a key pair — a private key that is kept secret, and a public key derived from it that can be freely shared — where operations with one key can only be undone with the other.

The breakthrough came in 1976 when Whitfield Diffie and Martin Hellman published "New Directions in Cryptography" — the paper that introduced the concept of public-key exchange. In 1977, Ron Rivest, Adi Shamir, and Leonard Adleman invented RSA, the first practical public-key encryption system. These ideas are now foundational to internet security (TLS), email encryption (PGP), and — most relevantly — blockchain ownership and digital signatures.

In a blockchain context, the key pair serves one purpose: proving ownership. Yourprivate key is a secret random number, typically 256 bits for Ethereum and Bitcoin. Your public key is derived from the private key using an irreversible mathematical operation — specifically, elliptic curve scalar multiplication. Your address is derived from the public key by hashing. To spend funds or interact with a contract, you sign a message with your private key; anyone can verify the signature using your public key without ever seeing the private key.

Elliptic Curve Cryptography

Both Bitcoin and Ethereum use elliptic curve cryptography (ECC) — specifically the secp256k1 curve — for their key pairs and digital signatures. ECC achieves equivalent security to RSA with dramatically shorter keys: a 256-bit ECC key provides approximately the same security as a 3,072-bit RSA key.

An elliptic curve over a finite field is the set of points satisfying the equation y² = x³ + ax + b (mod p), where p is a large prime and a, b are constants. The secp256k1 curve used by Bitcoin and Ethereum has a = 0 and b = 7, giving y² = x³ + 7 (mod p). The prime p is2²⁵⁶ − 2³² − 977, a 256-bit prime that is close to 2^256.

The security of ECC rests on the discrete logarithm problem: given a point G (the generator) and a point P = k·G (the result of adding G to itself k times), it is computationally infeasible to find k. Here, "adding" points uses the elliptic curve group law — a geometric operation where the line through two points on the curve is reflected to produce a third point. This operation is easy in the forward direction (k multiplications of G) but has no known efficient inverse.

In practice: your private key is k (a random 256-bit integer); your public key is the point P = k·G on the secp256k1 curve. The curve's generator point G has a fixed, publicly known (x, y) coordinate. Given only k, computing P is fast (logarithmic in k using double-and-add). Given only P, finding k requires solving the elliptic curve discrete logarithm — considered infeasible for secp256k1 with current classical computers.

Alternative curves appear in other blockchain contexts. Ed25519(Edwards curve, used by Solana, Cardano, and many others) offers faster signature generation, deterministic signatures (removing a source of nonce reuse vulnerabilities), and simpler implementation than secp256k1. BLS12-381 (used by Ethereum's consensus layer) is a pairing-friendly curve that enables BLS signature aggregation — combining thousands of validator signatures into a single constant-size signature, which is critical for Ethereum's proof-of-stake consensus at scale.

Digital Signatures

A digital signature is a cryptographic proof that a specific private key authorised a specific message. In blockchain, every transaction carries a digital signature that proves the sender controls the funds being spent — without revealing the private key to anyone, including the network nodes validating the transaction.

Bitcoin and Ethereum use the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve. The signing algorithm works as follows:

1. 1
   Hash the message

   Compute z = H(message), where H is SHA-256 (Bitcoin) or Keccak-256 (Ethereum). Signing the hash rather than the message directly allows signatures over arbitrary-length data with fixed-size arithmetic.

2. 2
   Generate a nonce

   Choose a random integer k (1 ≤ k < n, where n is the curve order). This nonce must be secret, random, and never reused. Nonce reuse is catastrophic: with two signatures sharing the same k, anyone can recover the private key algebraically.

3. 3
   Compute r

   Compute the point R = k·G. The r component of the signature is the x-coordinate of R, reduced mod n: r = R.x mod n.

4. 4
   Compute s

   Compute s = k⁻¹(z + r·privKey) mod n. Here k⁻¹ is the modular inverse of the nonce. The signature is the pair (r, s).

5. 5
   Verify

   Given message, public key Q, and signature (r, s): compute u₁ = z·s⁻¹ mod n and u₂ = r·s⁻¹ mod n. Compute point X = u₁·G + u₂·Q. Accept the signature if X.x mod n = r.

The Ethereum transaction signature includes an additional byte v(the recovery ID, value 27 or 28 historically, or 35+chainId after EIP-155). This byte allows verifiers to recover the public key from the signature alone — without the signer providing their public key explicitly. This is how Ethereum nodes determine the sender address from a signed transaction: they recover the public key from (r, s, v) and hash it to get the address. The smart contract function ecrecover(hash, v, r, s)exposes this recovery operation to Solidity code, enabling signature-based authorisation patterns like EIP-712 typed structured data signing and EIP-2612 permit signatures.

Schnorr signatures, introduced to Bitcoin via the Taproot upgrade (November 2021), are an alternative to ECDSA with three advantages. First, they are linearly aggregatable: n parties can combine their public keys and produce a single signature that is valid for the aggregated key — enabling k-of-n multisig that is indistinguishable from a single-signer transaction on-chain, saving both fees and privacy. Second, they have a clean security proof in the random oracle model. Third, they are simpler to implement correctly than ECDSA. ECDSA was used in Bitcoin originally because Schnorr signatures were patent-encumbered until 2008.

BLS signatures (Boneh-Lynn-Shacham) go further than Schnorr: any number of signatures from any number of signers can be aggregated into a single 48-byte signature verifiable against the combined public key. Ethereum's consensus layer uses BLS signatures for validator attestations — rather than verifying hundreds of thousands of individual validator signatures per epoch, the network aggregates them, making consensus practical at scale.

Merkle Trees

A Merkle tree is a binary tree of hashes that creates a compact, tamper-evident commitment to a set of data. Any change to any single piece of data changes the root hash, and membership of any data item can be proven with a logarithmic-size proof rather than revealing the entire dataset. Merkle trees appear throughout blockchain architecture — in transactions, state, receipts, and cross-chain proofs.

The construction is recursive. Start with the leaf layer: each leaf is the hash of a data item (e.g. a transaction). Move up the tree: each parent node is the hash of the concatenation of its two children. Continue until there is a single root node — the Merkle root. For a set of n leaves, the tree has height log₂(n). If n is not a power of 2, the last leaf is typically duplicated.

The critical property is Merkle proofs (also called audit proofs or inclusion proofs). To prove that a specific leaf is part of a tree with a known root, you provide the leaf value and the sibling hashes along the path from leaf to root — one hash per level. A verifier can recompute the root from the leaf and sibling hashes and check it matches the known root. For a tree with 2^20 leaves (~1 million), a proof requires only 20 hashes (20 × 32 bytes = 640 bytes) regardless of how much data the tree contains.

Ethereum's state, transaction, and receipt data is stored in Merkle Patricia Tries(MPTs) — a combination of a Merkle tree and a Patricia trie (prefix tree). The trie structure allows efficient insertion, deletion, and lookup by key, while the Merkle structure provides tamper evidence and membership proofs. The trie is keyed by the Keccak-256 hash of the account address; each leaf stores the RLP encoding of the account state (nonce, balance, storage root, code hash).

Ethereum's upcoming Verkle tree upgrade (part of the roadmap toward statelessness) replaces the MPT with a Verkle tree — a similar structure but using vector commitments instead of hashes. Verkle proofs are much smaller than Merkle Patricia proofs (hundreds of bytes versus tens of kilobytes), enabling stateless clients to verify state transitions without holding the full state — a prerequisite for running an Ethereum node on a phone or browser tab.

Key Derivation & HD Wallets

Hierarchical Deterministic (HD) wallets, defined by BIP-32 and BIP-39, allow an unlimited number of key pairs to be generated from a single seed — and the entire wallet to be backed up with 12 or 24 words. This is the mechanism behind every modern non-custodial wallet from Metamask to Ledger.

BIP-39 specifies how to generate a human-readable backup. The process: generate 128 or 256 bits of entropy from a cryptographically secure random number generator; append a checksum (first bits of SHA-256 of the entropy); split into 11-bit groups; map each group to a word from the 2,048-word BIP-39 wordlist. The result is 12 words (128-bit entropy) or 24 words (256-bit entropy). These words are then converted to a 512-bit seed using PBKDF2-HMAC-SHA512 with 2,048 iterations and an optional passphrase (the "25th word").

BIP-32 specifies how to derive a tree of key pairs from the 512-bit seed. The seed is hashed with HMAC-SHA512 to produce a 64-byte master key: the left 32 bytes become the master private key, the right 32 bytes become the master chain code (additional entropy that prevents child key derivation without knowing the parent chain code). Child keys are derived by further HMAC-SHA512 operations combining the parent key, chain code, and index.

1. 1
   Generate entropy

   128–256 bits from /dev/urandom or hardware RNG. Never use a non-cryptographic source — predictable entropy has led to real wallet thefts.

2. 2
   Create mnemonic (BIP-39)

   Checksum + wordlist mapping produces 12–24 human-readable words. These words ARE your private key — treat them with the same security.

3. 3
   Derive seed

   PBKDF2(mnemonic + optional passphrase, 'mnemonic', 2048 rounds, SHA-512) → 512-bit seed. The passphrase acts as a 25th word that can create a plausibly deniable decoy wallet.

4. 4
   Derive master key (BIP-32)

   HMAC-SHA512(seed, 'Bitcoin seed') → 512-bit output. Left 32 bytes = master private key; right 32 bytes = master chain code.

5. 5
   Derive account keys (BIP-44)

   Follow the path m/44'/coin_type'/account'/change/index. For Ethereum: m/44'/60'/0'/0/0 is the first address, m/44'/60'/0'/0/1 the second, etc.

6. 6
   Compute public key and address

   Apply secp256k1 scalar multiplication to get the public key; hash with Keccak-256; take last 20 bytes for the Ethereum address.

BIP-44 defines the path structure for multi-currency HD wallets:m / purpose' / coin_type' / account' / change / address_index. The apostrophe denotes hardened derivation — a hardened child cannot be derived from the parent public key alone, preventing "extended public key leak" attacks where knowing an xpub and any child private key exposes the parent private key. Hardened derivation is standard for account-level paths; normal (non-hardened) derivation is used for address-level paths so that a watch-only wallet (holding only the xpub) can enumerate all receiving addresses.

Commitment Schemes

A cryptographic commitment scheme allows a party to commit to a value — binding themselves to it — while keeping it hidden until they choose to reveal it. It is the digital equivalent of writing a prediction in a sealed envelope: the envelope proves you committed before the outcome, and opening the envelope reveals your prediction. Commitments are used throughout DeFi, auctions, governance, and ZK systems.

A commitment scheme has two phases: commit and reveal. In the commit phase, the committer publishes C = Commit(value, randomness) — a hash of the value combined with a secret random value (the blinding factor). The binding property means the committer cannot later open C to a different value; the hiding property means the commitment reveals nothing about the value before opening. In the reveal phase, the committer publishes (value, randomness), and anyone can verifyCommit(value, randomness) = C.

The simplest commitment scheme is a hash: C = H(value || randomness). The randomness prevents dictionary attacks — without it, an observer could enumerate all possible values and check which one hashes to C. With a 256-bit random blinding factor, the commitment is computationally hiding under the pre-image resistance of H.

Pedersen commitments are an algebraically structured alternative to hash commitments, used in Bulletproofs and many privacy protocols. A Pedersen commitment to value v with blinding factor r is C = v·G + r·H, where G and H are independent generator points on an elliptic curve. Pedersen commitments areadditively homomorphic: the commitment to (v₁ + v₂) equals the sum of the commitments to v₁ and v₂. This allows verifiers to check that committed amounts balance (inputs = outputs) without learning the individual amounts — the foundation of confidential transaction systems like Monero and MimbleWimble.

Encryption in Blockchain

A common misconception is that blockchain data is encrypted. It is not — all transaction data on public blockchains is pseudonymous, not anonymous or encrypted. The actual use of encryption in blockchain is narrower: securing off-chain communication, protecting key material, and building privacy-preserving layers on top of the public ledger.

On-chain transaction data is stored in plaintext and visible to all nodes. Your private key controls access to your funds, but the amounts, addresses, and contract calls in your transactions are readable by anyone. This is why blockchain analytics firms can trace fund flows, and why true financial privacy requires additional cryptographic techniques (ZK proofs, confidential transactions, mixers) rather than simple encryption.

ECDH (Elliptic Curve Diffie-Hellman) is used for encrypted peer-to-peer communication between wallets and for stealth address protocols. Two parties with key pairs (a, A=a·G) and (b, B=b·G) can compute a shared secret: a·B = a·b·G = b·A = b·a·G. The shared secret is a point on the curve that only the two parties can compute, even over a public channel. This is the basis for encrypted mempool systems, private messaging (XMTP), and stealth address protocols where senders can derive a fresh address for each recipient without the recipient publishing a new address.

Symmetric encryption (AES-256-GCM is the standard) is used to encrypt private key material at rest — in hardware wallets, keystores (Ethereum's UTC/JSON format), and cloud backups. The keystore format encrypts the private key with a key derived from your password using a KDF (key derivation function) like Scrypt or PBKDF2, adding significant work per attempt to slow brute-force attacks. The symmetric key is never stored — it is rederived from the password each time the keystore is unlocked.

Post-Quantum Cryptography

Quantum computers running Shor's algorithm would break elliptic curve cryptography — recovering private keys from public keys in polynomial time. This is not an imminent threat, but it is a credible long-term one. The blockchain ecosystem needs to understand what is vulnerable, what is not, and what the migration path looks like.

Shor's algorithm solves the discrete logarithm problem efficiently on a quantum computer. Since ECC security rests entirely on the hardness of this problem, a sufficiently powerful quantum computer (estimated to require millions of high-quality qubits — current machines have thousands of error-prone qubits) could recover any secp256k1 private key from the corresponding public key. This means any exposed public key is at risk: if you have ever signed a transaction, your public key is on-chain and could be targeted.

Critically, quantum computers do not break hash functions to the same extent. Grover's algorithm provides a quadratic speedup for brute-force search, reducing SHA-256's effective security from 256 bits to 128 bits. 128-bit security is currently considered sufficient — so hash functions, Merkle trees, and addresses (which are hashes of public keys) retain reasonable security against quantum attack. However, any address that has ever sent a transaction (and thus revealed its public key) is more vulnerable than an address that has only received funds.

In 2024, NIST finalised the first post-quantum cryptography standards:CRYSTALS-Kyber (now ML-KEM) for key encapsulation, andCRYSTALS-Dilithium (ML-DSA) and FALCON for digital signatures. These algorithms are based on the hardness of lattice problems, which are believed to be resistant to both classical and quantum attacks. Their signatures are significantly larger than ECDSA (Dilithium signatures are ~2.4 KB vs 65 bytes for ECDSA), which would substantially increase transaction size and cost on existing blockchains.

Ethereum's roadmap includes a long-term account abstraction path toward quantum resistance: EIP-7212 (secp256r1 precompile for hardware wallet integration) and ERC-4337 (account abstraction) create a framework where accounts can use alternative signature schemes without protocol-level changes. Users willing to pay higher gas can already deploy account contracts that verify lattice-based signatures today. A protocol-level migration will require a coordinated hard fork — likely decades away, but the design decisions made now in L2s and new chains will determine how easy that migration is.