Randomness, Entropy, and Key Generation

Randomness seems simple but conceals important distinctions that determine security.

Randomness Hierarchy:

1. True Randomness (Physical)

1. Cryptographically Secure Pseudorandomness (CSPRNG)

1. Pseudorandomness (PRNG)

1. Weak/Biased Sources

Entropy Measurement:

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

Examples:

• 2 outcomes, equally likely

• 6 outcomes, log₂(6) ≈ 2.58

• 2^256 equally likely values

• Required for private keys

• "password": ~0 bits (in attacker's dictionary)

• "Tr0ub4dor&3": ~28 bits (follows patterns)

• Truly random 12 chars: ~72 bits

• Need: 256 bits of entropy

• Means: 2^256 equally likely keys

• No patterns, no predictability

Impact of Reduced Entropy:

- Possibilities: 2^256 ≈ 10^77
- Brute force: Impossible forever

- Possibilities: 2^128 ≈ 10^38
- Brute force: Still impossible

- Possibilities: 2^64 ≈ 10^19
- Brute force: Expensive but feasible

- Possibilities: 2^32 ≈ 4 × 10^9
- Brute force: Minutes on modern hardware

- Possibilities: 1 (attacker knows your key)
- Brute force: Instant

- Entropy loss is invisible
- Key looks random even if it isn't
- No way to tell compromised key from secure key
- Only discovered when funds stolen

---

Different sources provide vastly different entropy quality.

Hardware RNG (Best Source):

- Measures physical phenomena
- Thermal noise in resistors
- Shot noise in semiconductors
- Quantum effects

- Intel RDRAND/RDSEED instructions
- TPM (Trusted Platform Module)
- Hardware security modules (HSM)
- Dedicated hardware (OneRNG, etc.)

Properties:
✓ True randomness (physical source)
✓ High throughput (modern CPUs: Gbps)
✓ Independent of software state
✓ Cannot be predicted even with full system access

- Must trust hardware manufacturer
- Some historical concerns about backdoors
- Usually mixed with software entropy as hedge

OS-Level Entropy Collection:

- Keyboard/mouse timing
- Disk I/O timing
- Network packet timing
- Hardware RNG if available
- Interrupt timing jitter

- /dev/random: Blocks if entropy pool "depleted"
- /dev/urandom: Never blocks, always provides output
- Modern recommendation: Use /dev/urandom
- Both use same algorithm, blocking is outdated model

- Similar hardware/timing events
- TPM if available
- Process/thread information
- System state data

- Similar to Linux
- Also uses Secure Enclave on modern hardware

- All modern OS CSPRNGs are suitable for crypto
- Collect entropy continuously from boot
- Generally trustworthy for key generation

NEVER Use for Cryptography:

- Predictable within narrow range
- Attacker knows approximate generation time
- Maybe 30-40 bits of uncertainty at best
- Fatal for key generation

- Limited range (typically 16-32 bits)
- Often sequential
- Predictable if attacker knows system state

- Humans are terrible at randomness
- Patterns in typing, mouse movement
- Can supplement but not replace good RNG

- Not cryptographically secure
- State can be recovered from outputs
- Designed for statistics, not security

- Fixed per device
- Zero entropy after first use
- Trivially discoverable

- XOR of 10 bad sources = still bad
- Attacker can enumerate combinations
- Need at least ONE good source

Defense in Depth for Randomness:

Best Practice: Combine multiple sources

1. Hardware RNG (if available)
2. OS entropy pool
3. Timing jitter from user actions
4. Environmental noise

- Hash all sources together
- HKDF or similar KDF
- Output is at least as random as best input

Example (libsodium approach):
entropy = HASH(
    hardware_rng_output ||
    os_random_bytes ||
    high_precision_timer ||
    process_memory_state
)

- If ANY source is good, output is good
- Attacker must compromise ALL sources
- Single source compromise doesn't break system
- Standard practice in security-critical systems

---

Real-world entropy failures provide crucial lessons.

The Vulnerability:

- Android Java's SecureRandom had initialization bug
- On some devices/versions, not properly seeded
- Output was predictable or repeatable

- SecureRandom.setSeed() replaced entropy, didn't add to it
- If called before system seeded pool: only user-provided seed used
- Many apps called setSeed() with predictable values
- Some devices had weak initial seeding

- ECDSA nonces generated with weak randomness
- Same nonces reused across different transactions
- Private keys recoverable from blockchain analysis
- Funds stolen from affected wallets

- 55 addresses compromised
- Approximately 55 BTC stolen (value then ~$5,500)
- Could have been much worse if not discovered

- Don't trust single entropy source
- Test randomness quality
- Update software promptly
- RNG failures are invisible until exploited

The Vulnerability:

- Debian maintainer "fixed" Valgrind warning
- Accidentally removed most entropy sources from OpenSSL
- Two years before discovery (2006-2008)

- Comment in code: "// MD_Update(&m,buf,j);"
- This line added entropy from various sources
- Removal left only process ID as entropy
- PID range: ~32,768 possible values

- All SSL keys generated on Debian/Ubuntu compromised
- SSH keys: trivially enumerable
- Researchers generated all possible keys in hours
- Mass SSH server compromise possible

- Two years of key generation affected
- Unknown number of compromised keys
- Required mass key regeneration
- Some keys may still be in use (!)

- Code review for security-critical changes
- Understand what security code does before modifying
- Test entropy quality, not just functionality
- Audit cryptographic libraries carefully

Pattern of Failures:

- Same nonce used for all signatures
- Private code signing key extracted
- PlayStation 3 security completely broken

- Weak nonces from implementation bugs
- Lattice attacks extracting keys from biased nonces
- Even partial bias (few bits) is exploitable

- Transaction signing with weak randomness
- Private keys recovered from on-chain signatures
- Automated theft once vulnerability discovered

- Nonce generation critical for ECDSA
- Any weakness in nonce → key compromise
- EdDSA eliminates this by design

Historical JavaScript Problems:

- Not cryptographically secure (by design)
- State recoverable from outputs
- Some browsers had weak implementations

- Used Math.random() for key generation
- Keys predictable to anyone who knew browser state
- Led to creation of window.crypto.getRandomValues()

- Modern secure alternative
- Uses OS CSPRNG
- Available in all modern browsers
- Required for browser-based crypto

- Modern browsers: getRandomValues() is secure
- Legacy browsers: May have issues
- Server-side generation preferred for high value

---

Different security requirements demand different procedures.

Standard Personal Use:

Acceptable Methods:
✓ Hardware wallet (generates internally)
✓ Reputable software wallet (uses OS entropy)
✓ Command line with verified tools

1. Purchase from authorized reseller
2. Verify device integrity
3. Initialize on device (generates seed)
4. Record seed phrase immediately
5. Verify recovery works before funding

1. Use known, audited wallet software
2. Generate on clean, updated OS
3. Disconnect from network during generation
4. Record seed phrase offline
5. Verify recovery before significant deposits

- 128+ bits entropy (12-word seed minimum)
- CSPRNG from OS or hardware
- Offline seed phrase recording
- Recovery verification

Enhanced Security ($100K+ holdings):

1. Boot from clean USB OS (Tails, etc.)
2. Never connect to network
3. Generate keys using verified software
4. Record on physical medium
5. Securely destroy digital copies
6. Verify recovery on separate air-gapped device

- Hardware RNG verification
- Multiple entropy sources
- Witness for process integrity
- Documented procedure
- Regular security audits

- Defined roles (generator, witnesses, auditor)
- Documented procedures
- Tamper-evident storage
- Chain of custody records

Institutional Requirements:

- FIPS 140-2 Level 3+ certified
- Keys generated and stored in HSM
- Never exported in plaintext
- Audit logs for all operations

- Key shares generated separately
- Combined without single party seeing full key
- Threshold signatures for spending
- Geographic distribution of shares

- Written procedures
- Audit trails
- Access controls
- Incident response plans
- Regular security assessments

- SOC 2 Type II certification
- Key management policy documentation
- Regular third-party audits
- Insurance requirements

Verification Approaches:

- Frequency test (equal 0s and 1s)
- Runs test (no excessive patterns)
- Longest run test
- Matrix rank test
- Many others...

Practical Testing:
# Generate random bytes
dd if=/dev/urandom bs=1M count=10 > random_data

# Run NIST tests (using ent or similar)
ent random_data

- Entropy: >7.9 bits per byte
- Chi-square: Not significant
- Arithmetic mean: ~127.5
- Serial correlation: ~0

- Statistical tests detect obvious problems
- Cannot prove randomness
- Can only fail to find patterns
- Passing tests ≠ guaranteed secure

---

Hardware wallets deserve special attention as primary key generation devices.

Typical Hardware Wallet Design:

1. Hardware TRNG (thermal noise)
2. User interaction (button presses, timing)
3. Environmental sensors (if present)

- Raw entropy → Conditioning function
- DRBG (deterministic random bit generator)
- Final output for key generation

- Dedicated chip for crypto operations
- Tamper-resistant
- Keys generated and stored internally
- Never exported in plaintext

- Must trust manufacturer
- Firmware is typically proprietary
- Some offer partial open source
- Third-party audits available for major brands

Evaluation Criteria:

Entropy Quality:
□ TRNG based on physical source
□ Conditioning meets standards (SP 800-90B)
□ Multiple entropy sources combined
□ Regular health checks on RNG

Firmware Security:
□ Signed firmware updates
□ Secure boot process
□ Open source or audited
□ Reproducible builds (if open source)

Physical Security:
□ Tamper-evident packaging
□ Secure element for key storage
□ Protection against glitching/side-channel
□ Self-destruct on tamper detection

Supply Chain:
□ Direct from manufacturer
□ Verify authenticity
□ Check for tampering
□ Initialize fresh (don't use pre-configured)

User-Side Verification:

What You Can Check:
✓ Seed phrase is 12/24 valid BIP39 words
✓ Checksum is correct
✓ Device generates different seed if reset
✓ Recovery produces same addresses

What You Cannot Check:
✗ Internal RNG quality (trust manufacturer)
✗ Whether TRNG is actually random
✗ Absence of backdoors
✗ Firmware integrity (without source)

- Use reputable, audited brands
- Add passphrase (25th word) for extra entropy
- Multi-vendor multi-sig (don't trust single vendor)
- Watch for security disclosures

---

✅ Modern OS CSPRNGs are suitable for cryptographic key generation. Linux's /dev/urandom, Windows CryptGenRandom, and similar implementations have been extensively analyzed and are considered secure when properly seeded. Major vulnerabilities have been patched.

✅ Hardware RNGs provide true randomness suitable for high-security applications. Physical entropy sources (thermal noise, quantum effects) cannot be predicted even with full knowledge of system state. Major CPU vendors include hardware RNG instructions.

✅ Historical entropy failures demonstrate real-world impact. The Android SecureRandom bug, Debian OpenSSL bug, and numerous ECDSA nonce failures prove that entropy problems cause actual key compromises and theft.

⚠️ Hardware RNG trustworthiness depends on manufacturer integrity. Users cannot verify that hardware RNGs work as specified. Theoretical backdoors could make output predictable. Defense: combine with software entropy.

⚠️ Entropy quality cannot be proven, only tested for known weaknesses. Statistical tests can detect obviously bad randomness but cannot prove output is truly random. Passing tests is necessary but not sufficient.

⚠️ Mobile device entropy quality varies by manufacturer and OS version. While modern smartphones generally have adequate entropy, specific implementations vary and may have subtle weaknesses.

🔴 Entropy failures are invisible until exploitation. A compromised key looks identical to a secure key. Users have no way to know their entropy was weak until funds are stolen.

🔴 Using Math.random() or non-cryptographic PRNGs for key generation is catastrophic. These are designed for statistics and games, not security. State can be recovered from outputs, enabling key prediction.

🔴 Weak entropy in ECDSA nonces is especially dangerous. Even slight bias (a few bits) can be exploited via lattice attacks to recover private keys from blockchain signatures.

Entropy is the invisible foundation of all cryptographic security. The mathematics of elliptic curves and hash functions are meaningless if the underlying randomness is predictable. Historical incidents prove this isn't theoretical—weak entropy has enabled real theft.

For most users, trusting hardware wallets or modern OS CSPRNGs is reasonable. For high-value storage, defense in depth (multiple entropy sources, hardware RNG, air-gapped generation) provides additional margins. The key insight is that entropy problems cannot be detected after the fact—prevention through proper generation procedures is the only defense.

---

Assignment: Create a comprehensive audit framework for evaluating key generation quality across different wallet types and use cases.

Requirements:

Part 1: Entropy Source Evaluation Matrix

• Source type (hardware RNG, OS, user input, etc.)
• Estimated entropy quality (bits)
• Verification methods available
• Known vulnerabilities
• Recommendations for use

Include at least 10 different entropy sources.

Part 2: Wallet Type Risk Assessment

• Hardware wallets (Ledger, Trezor, etc.)
• Desktop software wallets
• Mobile wallets
• Browser-based wallets
• Paper wallet generators
• Institutional HSM solutions

Part 3: Key Generation Procedure Templates

• Personal low-value ($1K-$10K)
• Personal high-value ($10K-$100K)
• Business operational
• Institutional custody

Each procedure should include step-by-step instructions.

Part 4: Incident Analysis

• Technical root cause

• How it was discovered

• Impact (funds lost, systems affected)

• Lessons for modern systems

• Comprehensiveness (30%)

• Technical accuracy (30%)

• Practical applicability (25%)

• Documentation quality (15%)

Time Investment: 4-5 hours

Value: This framework enables systematic evaluation of key generation security for any wallet or system, supporting due diligence for personal and institutional use.

---

For Next Lesson:
We begin Phase 2, examining XRPL's security architecture. Lesson 8 covers the transaction security model—how sequence numbers prevent replay attacks, how fees provide DoS protection, and how the validation pipeline ensures only authorized transactions modify ledger state.

---

End of Lesson 7

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