Key Derivation and HD Wallets

The foundation of any HD wallet is entropy—randomness that cannot be predicted or reproduced by attackers.

Entropy Basics:

Definition: Entropy measures unpredictability in bits.
n bits of entropy = 2^n equally likely possibilities

- Private keys: 256 bits of entropy
- Seed phrases: 128-256 bits of entropy
- "Secure" typically means 128+ bits

- Every atom in human body: ~7 × 10^27
- Atoms in Earth: ~10^50
- 128-bit space: larger than atoms in human body
- Brute force: computationally impossible

BIP39 Mnemonic Word Counts:

12 words: 128 bits entropy + 4 bits checksum = 132 bits
15 words: 160 bits entropy + 5 bits checksum = 165 bits
18 words: 192 bits entropy + 6 bits checksum = 198 bits
21 words: 224 bits entropy + 7 bits checksum = 231 bits
24 words: 256 bits entropy + 8 bits checksum = 264 bits

- BIP39 wordlist: 2048 words (2^11 = 2048)
- 12 words × 11 bits = 132 bits total
- Last 4 bits are checksum (SHA-256 of entropy)

12 vs 24 Words:
12 words (128-bit): Secure against all classical attacks
24 words (256-bit): Additional quantum resistance margin

- Personal use: 12 words sufficient
- High value / institutional: 24 words preferred
- Both are secure; 24 words = extra margin

BIP39 Process:

- Collect 128-256 bits from secure RNG
- Example: 128 bits for 12-word phrase

- Hash entropy with SHA-256
- Take first (entropy_bits / 32) bits
- Append to entropy

- 132 bits ÷ 11 bits = 12 groups
- Each group is number 0-2047

- Look up each number in BIP39 wordlist
- 2048 English words (standardized list)

Example:
Entropy: 0x7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f (128 bits)
Checksum: First 4 bits of SHA-256(entropy)
Combined: 132 bits
Split: [1023, 1023, 1023, ...]
Words: "legal winner thank year wave sausage..."

- Detects transcription errors
- Single word wrong → checksum fails
- Not security feature—error detection only

PBKDF2 Key Stretching:

Problem: Mnemonic is human-readable, needs transformation to cryptographic key

Solution: PBKDF2-HMAC-SHA512

seed = PBKDF2(
    password = mnemonic_words,
    salt = "mnemonic" + optional_passphrase,
    iterations = 2048,
    output_length = 512 bits
)

- Adds computational cost (2048 iterations)
- Slow = harder to brute force
- Standard key derivation function

- Added to salt: "mnemonic" + passphrase
- Different passphrase → completely different seed
- "25th word" for additional security
- Plausible deniability: different wallets from same mnemonic

- 512-bit seed (64 bytes)
- Used as master secret for HD derivation

---

The 512-bit seed becomes a tree of keys through BIP32 hierarchical derivation.

From Seed to Master Keys:

Process:
I = HMAC-SHA512(Key="Bitcoin seed", Data=seed)
Master secret key = I[0:32]  (first 256 bits)
Master chain code = I[32:64] (last 256 bits)

- Adds extra entropy to derivation
- Prevents derivation from public key alone (for hardened)
- Critical for security of child key generation

- Computed from master secret: K = kG
- Used for watch-only wallets
- Can derive child public keys (for non-hardened paths)

BIP32 Child Key Derivation:

1. Normal (non-hardened): indexes 0 to 2^31-1
2. Hardened: indexes 2^31 to 2^32-1 (written with ')

Normal Derivation (index i < 2^31):
I = HMAC-SHA512(chain_code, public_key || i)
child_key = parent_key + I[0:32]
child_chain_code = I[32:64]

Hardened Derivation (index i ≥ 2^31):
I = HMAC-SHA512(chain_code, 0x00 || private_key || i)
child_key = parent_key + I[0:32]
child_chain_code = I[32:64]

- Normal: Uses public key in derivation
- Hardened: Uses private key in derivation

Normal vs Hardened: Security Trade-offs

Normal (Non-Hardened) Derivation:
✓ Can derive child public keys from parent public key
✓ Enables watch-only wallets
✗ If child private key + parent chain code leak:
→ Parent private key can be computed!
→ All sibling keys compromised!

The Attack:
Given: child_private_key, parent_chain_code, parent_public_key
Compute: I = HMAC-SHA512(chain_code, public_key || i)
Then: parent_private_key = child_private_key - I[0:32]

Hardened Derivation:
✓ Child key leak doesn't compromise parent
✓ Isolated security per branch
✗ Cannot derive child public keys from parent public key
✗ No watch-only for hardened paths

BIP44 Derivation Paths:

Format: m / purpose' / coin_type' / account' / change / address_index

m         = Master key
purpose'  = 44' (BIP44 standard)
coin_type'= Coin identifier (144' for XRP)
account'  = Account index (0', 1', 2', ...)
change    = 0 for receive, 1 for change (0 for XRPL)
index     = Address within account (0, 1, 2, ...)

XRPL Example:
m/44'/144'/0'/0/0  = First address of first account
m/44'/144'/0'/0/1  = Second address of first account
m/44'/144'/1'/0/0  = First address of second account

- purpose': Identifies derivation standard
- coin_type': Separates coins (don't reuse keys!)
- account': Isolates accounts (hardened for security)
- change: Bitcoin convention (not really used in XRPL)
- index: Normal derivation for address generation

- 0': Bitcoin
- 60': Ethereum
- 144': XRP Ledger
- Full list: SLIP-0044

---

XRPL has some unique aspects in how it handles key derivation.

XRPL Account Key Options:

1. Standard Derivation (BIP44):

1. Native XRPL Derivation:

1. Raw Key Generation:

- secp256k1: Default, BIP44 compatible
- Ed25519: Add prefix to derivation
- Important: Same seed → different keys for different curves!

XRPL Accounts:

- Unlike Bitcoin/Ethereum with many addresses per account
- XRPL account is on-ledger object
- Requires 10 XRP reserve to activate

- Each derivation index can be separate XRPL account
- But each requires reserve
- Typically use fewer addresses than Bitcoin

Practical Pattern:
m/44'/144'/0'/0/0  → Primary account
m/44'/144'/1'/0/0  → Secondary account (if needed)

- Bitcoin: Many addresses, same wallet
- XRPL: Few accounts, each is independent ledger object

Seed Phrase Portability:

- Different wallets may use different derivation paths
- Same seed → different addresses in different wallets
- User thinks "recovery failed" when it actually worked

XRPL Ecosystem:
Wallet A: Uses m/44'/144'/0'/0/0
Wallet B: Uses m/44'/144'/0'/0/0 (compatible!)
Wallet C: Uses custom path (incompatible!)

1. Set up wallet with seed phrase
2. Generate first address
3. Record address
4. Restore in different wallet with same seed
5. Verify same address generated
6. Only then fund the account

- Use well-known, BIP44-compliant wallets
- Verify derivation path documentation
- Test recovery BEFORE depositing significant funds
- Keep record of derivation path used

---

Key derivation security depends on proper implementation and usage.

Weak Entropy Sources:

Bad Sources:
✗ System time (predictable)
✗ Process ID (limited range)
✗ User-chosen words (low entropy)
✗ Math.random() in JavaScript (not cryptographic)
✗ Unseeded PRNGs

- Early Bitcoin wallets: weak random generation
- Browser-based wallets: JavaScript RNG issues
- Android: SecureRandom seeding bug

Estimating Entropy:

• English vocabulary: ~20,000 common words

• But humans are bad at random

• Patterns, favorites, meaningful words

• Effective entropy: probably 30-40 bits

• Crackable in days, not centuries

• 128 bits from hardware RNG

• Uncrackable regardless of computing power

Related Key Attacks:

- Child private key
- Parent chain code
- Index used

And Derivation Was Non-Hardened:
→ Can compute parent private key
→ Can compute all sibling keys
→ Complete compromise of that branch

- Use hardened derivation for account separation
- Never expose child private key + chain code together
- Watch-only wallets: only expose public key + chain code

- xpub = public key + chain code
- Sharing xpub enables watching all addresses
- With ANY corresponding private key → full compromise
- Be careful who sees your xpub

Seed Phrase Attack Vectors:

- Written on paper: Can be photographed, stolen
- Metal backup: Can be physically taken
- Digital file: Can be hacked
- Cloud storage: Terrible idea

- "Enter seed to claim airdrop"
- Fake wallet apps requesting seed
- "Support" asking for recovery phrase
- NEVER enter seed anywhere except your wallet

- Malware monitors clipboard
- User copies seed → malware captures
- Some malware replaces pasted addresses

- Someone watches seed entry
- Security cameras in crypto meetups
- Screen sharing during calls (!)

- Pre-compromised hardware wallets
- Firmware with backdoor
- "Pre-configured" wallets with known seeds

Common Implementation Errors:

- BIP39 has specific 2048-word English list
- Some implementations use variants
- Recovery fails across wallets

- Unicode normalization affects checksum
- "é" vs "e" + combining accent
- BIP39 specifies NFKD normalization

- Starting from index 0 vs 1
- Different software conventions
- Funds "disappear" in recovery

- Some tools don't verify checksum
- Accept invalid mnemonics
- Leads to recovery failures

---

Practical guidance for secure key derivation and management.

Secure Seed Generation Checklist:

Hardware Requirements:
□ Use hardware wallet for generation (preferred)
□ Or: Air-gapped computer with verified OS
□ Or: Trusted software wallet with hardware RNG

Generation Process:
□ Generate in private, no cameras
□ Verify checksum word is valid
□ Write down immediately on paper
□ Verify by reading back
□ Generate test address
□ Verify test address derivation

What to Avoid:
✗ Generating on network-connected device
✗ Taking screenshot or photo
✗ Typing into any software before backup complete
✗ Using brain wallet (user-chosen words)
✗ Using online seed generators

Seed Backup Best Practices:

- Write on paper or stamp on metal
- Waterproof, fireproof storage
- Multiple geographic locations
- Safe deposit box (with considerations)

Storage Tiers by Value:

• Paper backup in secure location

• Consider metal backup for fire protection

• Test recovery annually

• Metal backup (Cryptosteel, etc.)

• Multiple locations (home + safe deposit)

• Consider geographic distribution

• Shamir's Secret Sharing for extra security

• Professional custody consideration

• Multiple redundant backups

• Geographic distribution

• Legal arrangements (estate planning)

• Regular security audits

Key Generation Comparison:

Hardware Wallets:
✓ Dedicated secure element
✓ Hardware random number generator
✓ Isolated from network attacks
✓ Key never leaves device
✗ Supply chain risks
✗ Firmware opacity
✗ Physical theft possible

Software Wallets:
✓ Code can be audited
✓ No supply chain hardware risk
✓ Convenient for frequent use
✗ Computer security dependent
✗ Entropy quality varies
✗ Malware vulnerable

- Middle ground
- Secure element on modern phones
- But phones connect to internet
- Good for moderate amounts

Recommendation by Use Case:
Daily spending: Mobile wallet (small amounts)
Trading account: Software wallet (with 2FA)
Long-term storage: Hardware wallet
Significant wealth: Multi-sig with hardware

Recovery Test Procedure:

1. Generate seed, write backup
2. Initialize wallet, note first address
3. Reset/wipe wallet completely
4. Restore from written backup
5. Verify same address generated
6. Only then: send funds to address

- Verify backup is readable
- Confirm recovery still works
- Update backup if degraded
- Test in different wallet software

- Backup is incomplete (missed word)
- Backup is illegible (poor handwriting)
- Wrong derivation path (different wallet)
- Water/fire damage to backup
- Can't find/access backup location

---

✅ BIP32/BIP39/BIP44 standards are mathematically sound and widely implemented. The cryptographic constructions (HMAC-SHA512, PBKDF2) are well-analyzed. The standards have been used safely to secure billions of dollars for over a decade.

✅ 128-bit entropy (12-word phrase) provides adequate security against all classical computing attacks. The search space is too large to brute force. Additional words provide quantum resistance margin but aren't required for classical security.

✅ Hardened derivation prevents child key compromise from affecting parent keys. The separation is mathematical, not procedural. Even if an attacker obtains a child private key and chain code, they cannot compute the parent key.

⚠️ Entropy quality is invisible and difficult to verify. Users cannot easily confirm their wallet's random number generator is working correctly. Historical failures show this is a real concern, not theoretical.

⚠️ Hardware wallet security depends on manufacturer trustworthiness. Secure elements are black boxes. Firmware is usually proprietary. Users must trust that the implementation matches the claims.

⚠️ Long-term seed phrase storage faces unknown threats. Will your metal backup survive 20 years? Will BIP39 standard still be supported? Estate planning for cryptocurrency is largely untested.

🔴 Seed phrase exposure is catastrophic and unrecoverable. Anyone who sees your seed can drain your funds. There's no "change password" option. Exposure events are often not immediately detected.

🔴 User-generated "random" words have dramatically less entropy than advertised. Humans are terrible at randomness. A "random" 12-word phrase chosen by a human might have only 30-40 bits of entropy—crackable with moderate computing resources.

🔴 Cloud backup or digital storage of seeds is extremely dangerous. Cloud services are hacked. Computers are compromised. The convenience is not worth the risk.

HD wallets are elegant cryptographic engineering that solves a real problem—secure, recoverable key management. The math is solid. The standards are mature.

The danger lies entirely in the human factors: entropy generation, backup security, recovery testing, and resistance to social engineering. The cryptography can't help you if you type your seed into a phishing site or store it in your email.

For most users, a hardware wallet with properly secured seed backup provides the best balance of security and usability. The hardware handles entropy and key isolation; you handle the physical security of the backup.

Assignment: Create a comprehensive security checklist and audit framework for evaluating HD wallet implementations and personal key management practices.

Requirements:

Part 1: Wallet Implementation Audit

• Entropy source verification
• BIP39/BIP32/BIP44 compliance
• Derivation path documentation
• Checksum validation
• Recovery testing capability
• Open source status
• Security audit history

Part 2: Personal Key Generation Procedure

• Hardware/software requirements
• Environmental controls
• Step-by-step generation process
• Verification steps
• Backup creation procedure
• Recovery test protocol

Part 3: Backup Security Assessment

• Physical durability
• Geographic distribution
• Access controls
• Fire/water resistance
• Estate planning integration
• Plausible deniability options

Include recommendations for different value tiers.

Part 4: Common Failure Modes

• How the failure occurs

• Warning signs

• Prevention measures

• Recovery options (if any)

• Comprehensiveness (30%)

• Practical applicability (30%)

• Security accuracy (25%)

• Documentation quality (15%)

Time Investment: 3-4 hours

Value: This checklist becomes a reference for personal security audits and for evaluating any wallet before trusting it with significant value.

For Next Lesson:
We'll examine address generation and verification—how public keys become XRPL addresses and how checksums prevent costly transmission errors. Understanding the complete path from key to address reveals the careful engineering that protects users from typos.

End of Lesson 5

Total words: ~5,600
Estimated completion time: 55 minutes reading + 3-4 hours for deliverable