L03: Cryptographic Foundations

Master the cryptographic primitives underlying blockchain: hash functions, public-key cryptography, digital signatures, and Merkle trees.

⏱️ Estimated Time: 3 hours for complete mastery

Learning Objectives

By the end of this study session, you will be able to:

  • Explain five properties of cryptographic hash functions
  • Understand the difference between symmetric and asymmetric encryption
  • Describe how public-key cryptography enables secure communication
  • Explain the process of creating and verifying digital signatures
  • Understand Merkle trees and their role in blockchain efficiency
  • Analyze security trade-offs in different cryptographic schemes
  • Apply cryptographic concepts to real blockchain scenarios

Study Path

Read Summary Slides

Start with the summary slides (PDF). Focus on SHA-256 examples and signature verification diagrams.

Watch Key Concepts

View recommended videos on public-key cryptography and digital signatures. These are complex topics that benefit from visual explanations.

Complete Practice Problems

Work through all 10 practice problems below. Several involve signature verification and hash calculations.

Take the Quiz

Test your knowledge with Quiz 3. This lesson has more technical depth.

Hands-On Challenge

Try the Crypto Treasure Hunt to apply concepts practically.

Key Concepts Summary

Cryptographic Hash Functions

Key Properties:

  • Deterministic: Same input → same output always
  • Fast computation: Efficient to calculate
  • Avalanche effect: Small change → completely different hash
  • One-way: Cannot reverse (preimage resistance)
  • Collision resistant: Hard to find two inputs with same hash

Common algorithms: SHA-256 (Bitcoin), Keccak-256 (Ethereum)

Symmetric vs. Asymmetric Encryption

Symmetric: Same key for encryption and decryption (fast, but key distribution problem)

Asymmetric (Public Key): Public key encrypts, private key decrypts (slower, but solves distribution)

Blockchain uses: Asymmetric for signatures, symmetric for bulk data encryption

Digital Signatures

Signing: hash(message) + private key → signature

Verification: signature + public key + message → valid/invalid

Properties: Authentication, integrity, non-repudiation

Bitcoin/Ethereum use: ECDSA (Elliptic Curve Digital Signature Algorithm)

Public/Private Key Pairs

Private key (secret) → Public key (shareable) → Address (account ID)

Critical rule: Never share private keys! They control funds and identity.

Key generation: Random number → private key → mathematical derivation → public key

Merkle Trees (Revisited)

Binary hash tree enabling:

  • Efficient verification with O(log n) proof size
  • Tamper detection - any leaf change invalidates root
  • Light client support - verify transactions without full blockchain

Practice Problems

Problem 1: Why is the avalanche effect important for proof-of-work? Explain how miners use it.
Answer: The avalanche effect means changing the nonce by 1 produces a completely unpredictable hash. This makes mining require brute force trial-and-error - there's no shortcut to find a hash below the target difficulty. Miners must try billions of nonces, hashing each time, until they randomly find one that works. Without avalanche effect, patterns could be exploited to speed up mining unfairly.
Problem 2: Alice wants to send Bob an encrypted message. Should she use Bob's public key or private key to encrypt? Who can decrypt it?
Answer: Alice uses Bob's public key to encrypt. Only Bob can decrypt using his private key. This is the beauty of asymmetric encryption - anyone can send encrypted messages to Bob using his publicly known key, but only Bob (with the private key) can read them. Public key = lock (anyone can lock), private key = key (only owner unlocks).
Problem 3: Explain how digital signatures provide "non-repudiation." Why can't Alice later deny sending a transaction she signed?
Answer: Only Alice possesses her private key (assuming she kept it secure). Creating a valid signature mathematically proves the signer had the private key corresponding to Alice's public key. Since only Alice should have this key, she cannot credibly deny signing the transaction. The signature is cryptographic proof of authorship. This is why private key security is critical - whoever controls the key controls the identity.
Problem 4: A blockchain address is derived from a public key, not the public key itself. Why add this extra step?
Answer: Two main reasons:
1. Shorter format: Hash of public key (address) is shorter than full public key, easier to share/write
2. Quantum resistance: If quantum computers break ECDSA, they need the public key to derive the private key. By hiding public keys behind an address (revealed only when spending), unused addresses remain secure even if ECDSA is broken. Public keys are only revealed when signing transactions.
Problem 5: Calculate: SHA-256 outputs 256 bits. How many possible hash values exist? Express in approximate number of atoms in the universe context.
Answer: Possible hashes = 2^256 ≈ 1.16 × 10^77
Atoms in observable universe ≈ 10^80

So SHA-256 has nearly as many possible outputs as there are atoms in the universe! This astronomical number makes collisions (two inputs with same hash) practically impossible. Even with all computers on Earth hashing for millennia, probability of finding a collision remains negligible.
Problem 6: An attacker steals a database of password hashes. Why can't they immediately log in as users, even with all the hashes?
Answer: Hash functions are one-way - knowing hash(password) doesn't reveal the password. The attacker must:
1. Try guessing passwords (brute force)
2. Hash each guess and compare
3. Match = found password

This is why strong passwords matter - weak/common passwords fall quickly to dictionary attacks. Systems add "salt" (random data) to make rainbow table attacks infeasible. In blockchain context, this one-way property prevents deriving private keys from public keys or addresses.
Problem 7: Compare: Why does Bitcoin use ECDSA signatures instead of RSA (common in web encryption)?
Answer: ECDSA advantages for blockchain:
1. Shorter keys: 256-bit ECDSA key provides same security as 3072-bit RSA key → saves blockchain space
2. Smaller signatures: Reduces transaction size and fees
3. Faster verification: Important for nodes validating thousands of transactions

Trade-off: ECDSA signing is slightly slower, but blockchain cares more about verification speed (done by all nodes) than signing speed (done once by sender).
Problem 8: Merkle tree scenario - A block has 1024 transactions. How many hashes total are in the complete Merkle tree (including all levels)?
Answer: Levels in tree with 1024 leaves:
- Level 0 (leaves): 1024 transaction hashes
- Level 1: 512 hashes
- Level 2: 256 hashes
- Level 3: 128 hashes
- Level 4: 64 hashes
- Level 5: 32 hashes
- Level 6: 16 hashes
- Level 7: 8 hashes
- Level 8: 4 hashes
- Level 9: 2 hashes
- Level 10 (root): 1 hash

Total: 2047 hashes (sum of geometric series: 2^n - 1 = 2^11 - 1 = 2047)
Problem 9: Critical thinking - If hash functions are one-way, how does proof-of-work mining "reverse" them to find valid hashes?
Answer: They don't reverse them! This is a key misconception. Miners use brute force forward search:
1. Try nonce = 0, hash(block + 0) → check if valid
2. Try nonce = 1, hash(block + 1) → check if valid
3. Try nonce = 2, hash(block + 2) → check if valid
...
Repeat billions of times until finding a nonce whose hash meets difficulty target.

This isn't "reversing" - it's exhaustively trying inputs until output satisfies criteria. The one-way property ensures there's no shortcut.
Problem 10: Security scenario - You receive a transaction claiming to be from address 0xABC... with a signature. What steps verify it's authentic?
Answer: Verification steps:
1. Extract public key from signature (ECDSA allows public key recovery)
2. Derive address from extracted public key (hash and format)
3. Compare addresses: Does derived address match claimed sender 0xABC...?
4. Verify signature: Does signature match message + public key?
5. Both checks pass? Transaction is authentic

If either fails, transaction is forged. This process proves sender controls the private key for address 0xABC... without ever revealing that private key.

External Resources

Videos

Articles

Interactive Tools

Documentation

Self-Check Questions

Before moving to Lesson 4, ensure you can confidently answer these questions:

  • Can you list and explain all five properties of cryptographic hash functions?
  • Can you explain the difference between public and private keys?
  • Can you describe the complete process of creating and verifying a digital signature?
  • Can you explain why blockchain uses asymmetric rather than symmetric encryption?
  • Can you construct a Merkle proof for transaction verification?
  • Can you explain why private key security is critical?

If you answered "yes" to all, you're ready for Lesson 4: Consensus Mechanisms!