CS / Security — Waterloo

Merkle Tree Based Authentication
and Its Applications

Cheng Fang  ·  Jason Li

Root
H₀
H₁
UW
University of
Waterloo
02

Outline

🌲

Merkle Tree Overview

n=32 P2P setup, interactive verification

⚙️

How It Works

Gen / Retrieve / Verify operations

🔐

Security Model

Root trust, attack surface

💰

App 1 — Proof of Reserve

Crypto exchange solvency

🌐

App 2 — IPFS

Decentralised file storage

📊

Summary

Strengths, limitations & outlook

03

Merkle-tree Authentication  n = 32

32 P2P nodes each store a copy of file d.
We want to verify integrity without downloading the whole network.

1
Naive

O(n) bandwidth

2
Merkle

O(log n) proofs

⚡ INTERACTIVE: CLICK ANY LEAF (d₀ TO d₃₁) TO TRACE THE O(log n) PATH
04

How It Works

GEN
1

Compute 32 leaf hashes from data blocks

2

Build tree bottom-up

3

Publish the Merkle root via trusted channel

RETRIEVE(i)

Node returns a tuple:

IDUnique node identifier
sSalt value
dData block
σAuth path (sibling hashes)
VERIFY
1

Recompute leaf hash from received data

2

Follow auth path σ upward

3

Check computed root matches published

h(h(h(d,s)||σ₀)||σ₁) == Root
05

Security Model

Assumption: The published Merkle root is authentic and delivered via a trusted channel.

TAMPER DETECTION
  • Modify data d → leaf hash changes
  • Change ID or salt → leaf hash changes
  • Any change propagates up the tree
  • Computed root ≠ published root → detected
⚠️
Root Substitution Attack
If an adversary replaces the published root with a fraudulent one, all verifications become meaningless.
⚡ INTERACTIVE — CLICK TO TAMPER d₀
d₀ (orig)0xA1B2C3D4...
leaf hashH(A1B2)=9f3e...
root3a9b...
Click to simulate tampering →
06

Application 1  —  Proof of Reserve (PoR)

Motivation: Following exchange collapses, Merkle-tree PoR is the industry standard for proving solvency without leaking user balances.

LEAF NODE STRUCTURE
aᵢ = h(IDᵢ ‖ Bᵢ)
  • IDᵢ — User's unique identifier
  • Bᵢ — Account balance of user i
MERKLE ROOT SEMANTICS

The Merkle root represents the total liabilities of the exchange.

Root ↔ Σ all user liabilities
EXCHANGE PUBLICATION
1

Publish Merkle_root publicly

2

Send each user their leaf + σ

3

Users verify locally

07

PoR — Critical Analysis

✓ PROS
  • High transparency
  • Preserves privacy of balances
  • O(log n) proof size
  • Fully local verification
✗ CONS
  • Only proves liabilities
  • Must pair with cold-wallet signatures
  • Snapshot-based
  • Requires root trust anchor

Key insight: PoR proves "we owe you X" but not "we own X." Complete solvency proof requires Merkle PoR plus cryptographic signatures from cold-wallet addresses.

08

Application 2  —  IPFS

1
Chunking

Files split into fixed-size blocks

2
Hashing → DAG

Each chunk is hashed into a Merkle DAG

3
CID generation

Root hash = Content Identifier

4
Integrity check

A single bit change alters the entire CID.

CID = CONTENT ADDRESS

Identical files yield the same CID, enabling deduplication at scale.

CID = H(Root(chunks))
✓ PROS
  • Massive deduplication
  • Tamper-proof
  • P2P with integrity
✗ CONS
  • Complex garbage collection
  • Data lost if not "pinned"
09

Summary & Takeaways

CORE PROPERTIES
  • O(log n) proof size
  • Collision resistance
  • Zero-knowledge privacy
  • Composable primitive

Merkle trees provide a universal primitive for authenticated data structures — underpinning Bitcoin, Ethereum, IPFS, and Certificate Transparency.

APPLICATIONS COVERED
💰
Proof of Reserve
Exchange liability verification
🌐
IPFS
Decentralized content addressing
Thank You
Cheng Fang  ·  Jason Li
University of Waterloo
1 / 9
← → ARROW KEYS  |  CLICK DOTS TO JUMP