Hash-Based Signatures - The Conservative Option
Learning Objectives
Explain how signatures can be built from hash functions alone
Compare stateful vs. stateless hash-based signature schemes
Analyze SLH-DSA (SPHINCS+) parameters and trade-offs
Assess when hash-based signatures are preferable to lattice-based
Evaluate HBS viability for XRPL applications
Hash-Based Security Assumption:
Only Requirement:
├── Hash function is one-way (preimage resistant)
├── Hash function is collision resistant
└── No other mathematical structure assumed
Why This Matters:
├── Lattice security: Assumes LWE is hard
├── RSA security: Assumes factoring is hard
├── ECC security: Assumes DLP is hard
├── HBS security: Only assumes hash is hard
Conservative Advantage:
├── Hash functions well-understood for decades
├── Multiple hash function choices available
├── If one hash breaks, substitute another
└── Minimal "attack surface" for cryptanalysis
Lamport Signature Concept (1979):
Key Generation:
├── For each bit position i of message hash:
│ ├── Generate two random values: sk[i][0], sk[i][1]
│ └── Publish hashes: pk[i][0] = H(sk[i][0]), pk[i][1] = H(sk[i][1])
├── Secret key: All sk values (256 pairs for 256-bit hash)
└── Public key: All pk values (512 hashes)
Signing:
├── Hash message m → h (256 bits)
├── For each bit i of h:
│ └── If h[i] = 0, reveal sk[i][0]; if h[i] = 1, reveal sk[i][1]
└── Signature: 256 revealed secret key values
Verification:
├── Hash message to get h
├── For each revealed value:
│ └── Check: H(revealed) = pk[i][h[i]]
└── Accept if all match
Critical Limitation:
└── ONLY ONE SIGNATURE EVER — reuse reveals more secret key
Merkle Tree Extension:
Problem: Lamport only signs once
Solution: Generate many one-time keys, organize in tree
Structure:
├── Generate 2^n one-time key pairs (leaves)
├── Build Merkle tree: parent = H(left || right)
├── Root becomes single public key
└── Each signature includes path to root
Signing:
├── Use leaf key i for message
├── Include Merkle path (log n hashes)
├── Verifier reconstructs root from path
└── Signature valid if root matches public key
Result:
├── 2^n signatures from one public key
├── But: Must track which leaves used (STATEFUL)
└── Reusing leaf = catastrophic security failure
XMSS (eXtended Merkle Signature Scheme):
Characteristics:
├── RFC 8391 standard
├── Tree height h determines signature count: 2^h
├── MUST track which leaves used (state)
├── Smaller signatures than stateless
Parameters Example (XMSS-SHA2_20):
├── Public Key: 64 bytes
├── Signature: 2,692 bytes
├── Max Signatures: 2^20 = 1,048,576
└── State: 20 bits (which leaf next)
Security:
├── Information-theoretic security (given hash security)
├── Cannot forge without breaking hash
└── State management is operational, not cryptographic issue
Danger:
├── If state lost/duplicated, same leaf may be used twice
├── Two signatures with same leaf → full secret key compromise
└── Requires careful state management infrastructure
LMS (Leighton-Micali Signatures):
Characteristics:
├── RFC 8554 standard
├── Similar concept to XMSS
├── Simpler, faster
├── Also stateful
Parameters Example (LMS_SHA256_H20):
├── Public Key: 60 bytes
├── Signature: 4,532 bytes
├── Max Signatures: 2^20
└── State: Must track leaf index
Use Cases:
├── Firmware signing (limited signatures okay)
├── Code signing
├── Certificate authorities
└── NOT suitable for high-frequency signing
SLH-DSA (Stateless Hash-Based Signatures):
Key Innovation:
├── Uses "hypertree" structure
├── Many one-time keys, selected by hash of message
├── Same key MIGHT be reused, but probability negligible
├── No state tracking required
Trade-off:
├── Stateless convenience
├── But: Much larger signatures (randomness adds overhead)
└── Size: 8 KB to 50+ KB depending on parameters
Security:
├── Relies on hash function + few-time signature security
├── Even if same key used twice (unlikely), still secure
├── No catastrophic state failure mode
└── NIST selected as backup standard
SLH-DSA Variants (FIPS 205):
"Small" Variants (s suffix) - Smaller signatures:
├── SLH-DSA-SHA2-128s: Public 32 B, Sig 7,856 B
├── SLH-DSA-SHA2-192s: Public 48 B, Sig 16,224 B
├── SLH-DSA-SHA2-256s: Public 64 B, Sig 29,792 B
"Fast" Variants (f suffix) - Faster signing:
├── SLH-DSA-SHA2-128f: Public 32 B, Sig 17,088 B
├── SLH-DSA-SHA2-192f: Public 48 B, Sig 35,664 B
├── SLH-DSA-SHA2-256f: Public 64 B, Sig 49,856 B
SHAKE Variants:
├── Same sizes, using SHAKE256 instead of SHA2
└── May be preferred for new applications
Key Observation:
├── Public keys are TINY (32-64 bytes)
├── Signatures are HUGE (8-50 KB)
└── Opposite trade-off from ML-DSA
SLH-DSA Performance (approximate):
| 128s | 128f | ML-DSA-65
--------------------|-----------|-----------|------------
Key Generation | ~10 ms | ~0.5 ms | ~0.1 ms
Signing | ~100 ms | ~5 ms | ~0.3 ms
Verification | ~5 ms | ~0.5 ms | ~0.05 ms
Public Key | 32 B | 32 B | 1,952 B
Signature | 7,856 B | 17,088 B | 3,293 B
Analysis:
├── SLH-DSA signing is 15-300× slower than ML-DSA
├── Verification is 10-100× slower
├── Signatures 2-5× larger (even "small" variant)
├── Public keys are much smaller
└── Performance penalty is significant
SLH-DSA Advantages:
Scenario 1: Maximum Security Assurance
├── Don't trust lattice assumptions long-term
├── Willing to pay size/performance cost
└── Hash assumption is most conservative
Scenario 2: Infrequent Signing
├── Sign rarely (certificates, firmware)
├── Verify often
├── Signing speed less critical
Scenario 3: Small Public Key Needed
├── Public keys must be embedded in constrained space
├── Signature size budget is larger
└── Opposite trade-off from ML-DSA
Scenario 4: Backup Algorithm
├── Defense in depth with ML-DSA
├── If lattice broken, fall back to SLH-DSA
└── Hybrid schemes possible
SLH-DSA for XRPL:
Advantages:
├── Most conservative security assumption
├── Tiny public keys (could simplify addressing)
├── No mathematical "structure" to attack
└── If lattice crypto breaks, HBS is backup
Disadvantages:
├── Signatures 8-50 KB (vs. 3.3 KB ML-DSA)
├── Verification 100× slower than ML-DSA
├── Transaction sizes would explode
├── Network throughput significantly impacted
└── Probably not practical as PRIMARY algorithm
Verdict:
├── Likely NOT primary XRPL PQ algorithm
├── Possible as OPTIONAL high-security choice
├── Could be backup if lattice concerns emerge
└── May see use in validator key signing
Where SLH-DSA Could Fit in XRPL:
1. Amendment Signing:
1. UNL Publisher Signatures:
1. Optional Account Type:
1. NOT for Regular Transactions:
Combining ML-DSA + SLH-DSA:
Hybrid Signature:
├── Sign with both algorithms
├── Signature valid if EITHER verifies
├── If ML-DSA broken: SLH-DSA still protects
├── If SLH-DSA broken: ML-DSA still protects
└── Size: Sum of both signatures (~11 KB)
Use Case:
├── High-value transactions
├── Long-term escrows
├── Maximum assurance requirements
└── Accept size penalty for security
XRPL Implementation:
├── Could be optional transaction type
├── Amendment to enable hybrid signing
├── User choice per transaction/account
└── Not mandatory (size impact too large)
Stateful HBS (XMSS/LMS) Risks:
The State Problem:
├── Must track which leaves have been used
├── State must persist across restarts
├── State must not be duplicated
└── Failure = catastrophic key compromise
Scenarios That Break Stateful HBS:
Database Corruption:
Backup Restoration:
Hardware Failure:
Distributed Systems:
Strategies for Safe Stateful HBS Use:
1. Single-Use Hardware:
1. State Reservations:
1. Avoid Stateful for Blockchain:
---
Proven: Hash function security is well-understood; HBS construction is mathematically clean; no quantum speedup beyond Grover's.
Uncertain: Whether large signature sizes are acceptable for blockchain; whether verification speed matters at scale.
Risky: Dismissing HBS as "too large" without considering use cases; ignoring state management risks in XMSS/LMS; assuming lattice will never need backup.
Assignment: Assess hash-based signatures for a specific use case.
Part 1: Compare SLH-DSA-SHA2-128s vs. SLH-DSA-SHA2-128f trade-offs (20%)
Part 2: Calculate transaction size impact if XRPL used SLH-DSA (20%)
Part 3: Design a state management system for XMSS in enterprise setting (25%)
Part 4: Propose hybrid ML-DSA + SLH-DSA scheme for high-value XRPL escrows (25%)
Part 5: Recommend when XRPL should consider HBS migration (10%)
Time Investment: 2-3 hours
1. HBS security relies only on: Answer: Hash function being one-way/collision-resistant
2. The danger of stateful HBS (XMSS/LMS) is: Answer: State duplication/loss causes key compromise
3. SLH-DSA signature size for 128-bit security (small variant): Answer: ~8 KB
4. Why is SLH-DSA unlikely as XRPL's primary PQ algorithm? Answer: Signatures too large for every transaction
5. SLH-DSA public keys are: Answer: Very small (32-64 bytes)
End of Lesson 10
Key Takeaways
HBS relies only on hash function security
— Most conservative cryptographic assumption
Stateful (XMSS/LMS) vs. Stateless (SLH-DSA)
— Stateless is safer for most applications
SLH-DSA signatures are large (8-50 KB)
— Trade-off for conservative security
Unlikely to be XRPL's primary algorithm
— ML-DSA is more practical at ~3.3 KB
Valuable as backup option
— If lattice assumptions weaken, HBS is ready ---