Algorithm Selection for Blockchain Applications

PQC Algorithm Evaluation Criteria:

Security (Weight: 30%):
├── Security level (1-5)
├── Cryptanalysis maturity
├── Conservative assumptions
└── Backup options if concerns arise

Signature Size (Weight: 25%):
├── Bytes per signature
├── Impact on transaction size
├── Storage multiplication
└── Fee implications

Verification Performance (Weight: 20%):
├── Microseconds per verification
├── Scalability at high TPS
├── CPU/memory requirements
└── Hardware acceleration potential

Signing Performance (Weight: 10%):
├── Milliseconds per signature
├── User experience impact
├── Hardware wallet compatibility
└── Battery/resource consumption

Public Key Size (Weight: 10%):
├── Bytes per public key
├── Address derivation impact
├── Account storage overhead
└── Multi-sig multiplication

Ecosystem Support (Weight: 5%):
├── Library availability
├── Hardware wallet support
├── Audit coverage
└── Community familiarity

Algorithm Comparison for XRPL:

| ML-DSA-44 | ML-DSA-65 | ML-DSA-87 | SLH-DSA-128s
--------------------|-----------|-----------|-----------|-------------
Security Level      | 2         | 3         | 5         | 1
Public Key (bytes)  | 1,312     | 1,952     | 2,592     | 32
Signature (bytes)   | 2,420     | 3,293     | 4,595     | 7,856
Verify (μs)         | ~30       | ~50       | ~80       | ~2,000
Sign (ms)           | ~0.2      | ~0.3      | ~0.5      | ~50
Library Support     | Excellent | Excellent | Excellent | Good

Weighted Score (100 point scale):
├── ML-DSA-44: 78 (smaller, but security margin lower)
├── ML-DSA-65: 82 (best balance) ✓ RECOMMENDED
├── ML-DSA-87: 71 (overkill size for minimal security gain)
├── SLH-DSA-128s: 55 (conservative but too large/slow)

Why ML-DSA-65 for XRPL:

Security:
├── Level 3: 128-bit quantum security
├── Same as current secp256k1 classical security
├── Well-analyzed, conservative parameters
└── No known attacks after NIST competition

Size:
├── Signature: 3,293 bytes (46× current, but manageable)
├── Public key: 1,952 bytes (59× current)
├── Transactions: ~3.5-4 KB typical (was ~300 bytes)
└── Acceptable for blockchain use case

Performance:
├── Verification: ~50 μs (fast enough for consensus)
├── Signing: ~0.3 ms (imperceptible to users)
├── Better than SLH-DSA by 40-100×
└── Hardware-accelerated implementations available

Ecosystem:
├── NIST primary standard (most library support)
├── Same algorithm family as ML-KEM (code reuse)
├── Broad industry adoption expected
└── Most audited implementation path

SLH-DSA for High-Assurance Use Cases:

When to Use:
├── If lattice cryptanalysis concerns emerge
├── For very high-value, infrequent transactions
├── Optional "paranoid" account type
└── Validator key signatures (infrequent)

Variant Choice: SLH-DSA-SHA2-128s
├── Smallest signatures in family (~8 KB)
├── SHA-2 based (familiar, well-audited)
├── Level 1 security (128-bit quantum)
└── Slower but acceptable for rare use

Implementation Approach:
├── Enable via separate amendment
├── Optional account configuration
├── Higher fees for larger transactions
└── Not default, user opt-in

Recommended XRPL Hybrid Approach:

Phase 1: Hybrid Available (2026-2028)
├── secp256k1 + ML-DSA dual signature option
├── Users can choose classical, PQ, or hybrid
├── Hybrid recommended for high-value accounts
└── No forced migration

Phase 2: PQ Encouraged (2028-2032)
├── ML-DSA-only accounts default for new accounts
├── Hybrid still available
├── Classical-only deprecated but supported
└── Migration tools and education

Phase 3: PQ Required (2032+)
├── Classical-only accounts disabled
├── Existing classical accounts must migrate
├── Hybrid or PQ-only enforced
└── Timeline depends on quantum progress

XRPL Transaction with ML-DSA:

Current Format:
├── Header: ~20 bytes
├── Payload: Variable (~100-200 bytes typical)
├── Signature: ~71 bytes (secp256k1)
└── Total: ~200-300 bytes

PQ Format:
├── Header: ~20 bytes (unchanged)
├── Payload: Variable (unchanged)
├── Signature: ~3,293 bytes (ML-DSA-65)
├── Public key in signature: 1,952 bytes (may be omitted if known)
└── Total: ~3,500-4,000 bytes

Optimization Options:
├── Public key omission (derive from account)
├── Signature compression (if available)
├── Aggregation (future research)
└── Progressive: Higher fees offset storage

Multi-Sig with ML-DSA:

Current Multi-Sig (3-of-5):
├── 5 public keys: 165 bytes
├── 3 signatures: ~213 bytes
├── Overhead: ~378 bytes
└── Manageable

PQ Multi-Sig (3-of-5):
├── 5 public keys: 9,760 bytes
├── 3 signatures: 9,879 bytes
├── Overhead: ~19,639 bytes
└── Significant but still feasible

Mitigation Options:
├── Threshold signatures (single aggregated signature)
├── Not yet standard for ML-DSA
├── Research area; may reduce in future
└── For now: Accept larger multi-sig transactions

Building for Algorithm Changes:

Design Principles:
├── Don't hardcode single algorithm
├── Amendment system enables additions
├── Account-level algorithm selection
├── Support algorithm deprecation

Practical Implementation:
├── Algorithm identifier in signatures
├── Versioned key formats
├── Clear upgrade paths
├── Backward compatibility windows

Future Possibilities:
├── Compact signature schemes (if developed)
├── Signature aggregation standards
├── Hybrid optimization
└── New NIST standards (additional signatures track)

Ongoing Evaluation Process:

Monitor:
├── Cryptanalysis publications
├── NIST updates and guidance
├── Quantum computing progress
├── Ecosystem adoption rates

Adapt:
├── Adjust security level recommendations
├── Update parameter choices if needed
├── Add new algorithms via amendments
└── Deprecate algorithms if broken

Triggers for Concern:
├── Significant lattice attack improvements
├── New quantum algorithm discoveries
├── NIST security level downgrades
└── Industry-wide algorithm changes

Proven: ML-DSA-65 offers best balance for blockchain; SLH-DSA provides conservative backup; hybrid approach is industry standard.

Uncertain: Whether signature aggregation will become practical; timeline for hardware wallet support; exact fee adjustments needed.

Risky: Choosing Level 5 unnecessarily (size penalty without security gain); ignoring hybrid option; assuming one algorithm forever.

Assignment: Write a formal algorithm selection proposal for XRPL.

Part 1: Executive summary recommending primary algorithm with justification (20%)
Part 2: Detailed comparison using weighted evaluation framework (25%)
Part 3: Transaction size and fee impact analysis (20%)
Part 4: Migration timeline with phases and triggers (20%)
Part 5: Risk assessment and mitigation strategies (15%)

Time Investment: 4-5 hours

1. Recommended primary PQC algorithm for XRPL: Answer: ML-DSA-65 (Level 3)

2. Why not ML-DSA-87 for maximum security? Answer: Size penalty without proportional security gain

3. Multi-sig transaction overhead with ML-DSA (3-of-5): Answer: ~20 KB

4. What makes SLH-DSA a good backup? Answer: Different security assumptions (hash only)

5. Key evaluation criterion unique to blockchain: Answer: Signature size (storage forever)

End of Lesson 13