Quantum Computing Threats

Understanding what quantum computers can do (and can't) requires grasping Shor's algorithm and Grover's algorithm.

What Shor's Algorithm Does:

- Integer factorization (breaks RSA)
- Discrete logarithm (breaks DH, DSA)
- Elliptic curve discrete logarithm (breaks ECC)

- Best classical factorization: Sub-exponential
- Best classical ECDLP: O(√n) ≈ 2^128 for 256-bit curves
- Both infeasible for current computers

- Factorization: O((log n)³) - polynomial
- ECDLP: O((log n)³) - polynomial
- Transforms infeasible → tractable

- RSA broken regardless of key size
- All ECC broken (secp256k1, Ed25519, P-256)
- Every current blockchain signature scheme fails

- Breaking 256-bit ECC: ~2,500-4,000 logical qubits
- But: Need error correction (1,000-10,000 physical qubits per logical)
- Total: Millions of physical qubits with low error rates
- Current state (2024): ~1,000 physical qubits, high error rates

Simplified Explanation (Conceptual):

Classical Approach to ECDLP:
Given: Public key Q = kG
Find: Private key k
Method: Try all possible k values
Time: ~2^128 attempts (infeasible)

1. Create quantum superposition of all possible k values

1. Apply quantum operations that "mark" correct k

1. Quantum Fourier Transform extracts period

1. Period reveals k

- Superposition: 2^n states simultaneously
- Entanglement: Correlations between qubits
- Interference: Amplifying correct answers
- No classical shortcut to simulate these effects

Key Insight:
Not "trying answers faster"
Rather: Exploiting quantum physics to find structure
that classical computers can't access

What Grover's Algorithm Does:

- Unstructured search (finding needle in haystack)
- Inverting functions (finding input for given output)

- Search N items: O(N) average
- For N = 2^128: ~2^128 operations

- Search N items: O(√N)
- For N = 2^128: ~2^64 operations

Impact on Cryptography:

• Pre-image resistance: 256-bit → 128-bit effective

• Collision resistance: 128-bit → 64-bit effective

• SHA-256 still provides 128-bit security against Grover

• Concerning but not catastrophic

• AES-256 → AES-128 effective security

• AES-256 remains secure (128-bit is adequate)

• Double key sizes solve the problem

• Grover: Quadratic speedup (still exponential work)

• Shor: Exponential speedup (makes problem tractable)

• Grover weakens but doesn't break hash/symmetric

• Shor completely breaks ECC

Quantum-Resistant Cryptography:

Unaffected by Shor's Algorithm:

1. Symmetric Encryption (AES):

2. Hash Functions (SHA-256):

3. Post-Quantum Algorithms:

• XRP itself isn't "broken" (stored value preserved)
• Transaction authorization is broken (signatures)
• Migration path exists (change signature scheme)
• Not an overnight apocalypse

Assessing the threat requires understanding where quantum computing actually stands.

Current Capabilities:

- IBM: ~1,000 qubits, roadmap to 100,000+ by 2033
- Google: ~100 qubits, achieved "quantum supremacy" (narrow task)
- IonQ: ~30 trapped ion qubits, high quality
- D-Wave: ~5,000 qubits (quantum annealing, different paradigm)
- Various startups and national programs

Current Limitations:

1. Qubit Count:

2. Error Rates:

3. Coherence Time:

4. Error Correction:

Expert Consensus (as of 2024-2025):

- 2030-2035: Cryptographically relevant quantum computer
- Requires major breakthroughs
- Assumes aggressive progress continues

- 2035-2045: Possible cryptographically relevant system
- Gradual progress with current approaches
- Error correction is main bottleneck

- 2045+: May take longer or never be practical
- Fundamental obstacles may be harder than expected
- Decoherence may be intractable at scale

- ~4,000 error-corrected logical qubits
- Sustaining computation for hours
- Reliable Shor's algorithm execution

Key Uncertainty:
Progress is not linear or predictable
Breakthroughs could accelerate
Fundamental limits could slow/stop progress
Neither panic nor complacency is warranted

Notable Progress (2020-2024):

- 53 qubits solved specific problem
- Faster than classical supercomputers
- BUT: Narrow task, no crypto relevance

- 1,000+ qubits demonstrated (2023)
- 100,000 qubits planned by 2033
- Error rates still problematic

- First demonstrations of logical qubits
- Still far from practical scale
- Active area of research

- Photonic quantum computers
- Large qubit counts achieved
- Different approach with different limitations

- Multiple approaches being pursued
- IonQ, Rigetti, PsiQuantum, others
- Billions in investment

What This Means:
Progress is real but crypto-breaking is still distant
Timeline remains highly uncertain
The problem is engineering, not physics (probably)

The most concerning near-term quantum threat isn't breaking encryption today—it's collecting encrypted data to break later.

Harvest Now, Decrypt Later (HNDL):

1. Adversary collects encrypted data today
2. Stores it (storage is cheap)
3. Waits for quantum computer
4. Decrypts historical data

- Classified government communications
- Long-term secrets (trade secrets, medical records)
- Corporate communications
- Anything valuable in 10-20 years

- All transactions are public
- Account public keys are exposed
- No need to "harvest"—already public
- When quantum arrives, derive private keys from public keys

XRPL Quantum Exposure:

- Public key exposed on-ledger
- Anyone can see the public key
- Quantum computer → private key → drain account

When Public Keys Are Exposed:

1. First transaction:

2. Account creation:

3. Multi-sig configuration:

Risk Levels:

• Public key on ledger

• Cannot be hidden

• Must migrate before quantum threat

• If only received funds

• If never signed transaction

• Public key may not be exposed yet

• Use post-quantum signatures from start

• When available on XRPL

Comparative Quantum Vulnerability:

- Address = hash of public key
- Public key only revealed when spending
- Unspent outputs: Only hash exposed
- Grover reduces hash security to 80-bit (still hard)
- Slightly better position for dormant addresses

- Account tied to single public key
- Public key exposed on first transaction
- Must sign to do anything
- Once exposed, permanently vulnerable
- No hash protection layer

- Active accounts fully exposed
- Migration required before quantum threat
- Similar timelines needed

- Both: Migrate to post-quantum signatures
- Both: Have years (likely) to prepare
- Key: Protocol must support PQ signatures

---

Solutions exist—the question is implementation and migration.

NIST PQC Standardization (Completed 2024):

Selected Algorithms:

1. ML-KEM (CRYSTALS-Kyber) - Key Encapsulation:

2. ML-DSA (CRYSTALS-Dilithium) - Digital Signatures:

3. SLH-DSA (SPHINCS+) - Hash-Based Signatures:

• Extensive analysis (years of competition)
• Multiple underlying problems (diversity)
• Performance acceptable for most uses
• Conservative security margins

Post-Quantum Signature Overhead:

Key Size    Sig Size    Speed
Ed25519 (current)   32 bytes    64 bytes    Very fast
ML-DSA-65           1,312 B     2,420 B     ~50x slower
ML-DSA-87           1,952 B     3,293 B     ~100x slower
SLH-DSA-SHA2-128s   32 bytes    8,080 B     ~200x slower
SLH-DSA-SHA2-256f   64 bytes    49,856 B    ~1000x slower

Impact on XRPL:

• Current: ~200-300 bytes typical

• With ML-DSA: ~2,700-3,500 bytes

• 10x larger transactions

• Current: ~microseconds

• Post-quantum: Slower but still fast enough

• Network can handle it

• Larger transactions = higher fees

• ~10x fee increase for signatures

• Still very cheap in absolute terms

• Ledger grows faster

• Historical data larger

• Manageable with modern storage

XRPL Quantum Migration Challenges:

- New transaction types for PQ signatures
- Amendment process required
- Validator coordination
- Backward compatibility

- Generate new PQ keypairs
- Create new accounts (or migrate)
- Move funds from old to new accounts
- Update all integrations

- Wallets must support PQ
- Libraries need updates
- Hardware wallets need firmware
- Exchanges need integration

- Migration takes years, not days
- Need to start well before quantum threat
- 5-10 year lead time recommended
- Announcement → Implementation → Migration

- Which algorithms will XRPL support?
- Migration incentives/requirements?
- Handling of unmigrated accounts?
- Transition period security?

---

Practical guidance for current decision-making.

For Individual XRP Holders:

Immediate (Now):
□ No panic—quantum computers don't exist yet
□ Continue using current security practices
□ Stay informed on quantum progress
□ Don't fall for "quantum-safe crypto" scams

Short-Term (1-3 years):
□ Monitor XRPL amendment proposals
□ Watch for post-quantum wallet support
□ Understand migration procedures when available
□ Prepare for eventual migration

Medium-Term (3-10 years):
□ Migrate when XRPL supports post-quantum
□ Don't wait for "last minute"
□ Test with small amounts first
□ Keep old and new accounts during transition

What NOT To Do:
✗ Panic sell because of quantum threat
✗ Invest in "quantum-proof" scam coins
✗ Ignore the issue entirely
✗ Wait until quantum computers exist to act

For Organizations Holding XRP:

Governance:
□ Include quantum risk in security policy
□ Assign responsibility for monitoring
□ Budget for eventual migration
□ Document current exposure

Technical Preparation:
□ Inventory all cryptographic systems
□ Identify quantum-vulnerable components
□ Evaluate post-quantum alternatives
□ Test PQ libraries in non-production

Migration Planning:
□ Develop migration runbook
□ Identify dependencies (wallets, integrations)
□ Plan communication to stakeholders
□ Estimate migration costs and timeline

Monitoring:
□ Track quantum computing advances
□ Follow NIST/industry standards
□ Monitor XRPL development
□ Maintain relationship with crypto experts

For XRPL Developers:

Library Preparation:
□ Monitor xrpl.js/ripple-lib for PQ support
□ Test PQ libraries (liboqs, etc.)
□ Understand signature size implications
□ Plan UI changes for larger signatures

Application Design:
□ Abstract signature algorithms
□ Design for algorithm agility
□ Consider future transaction size
□ Plan storage for larger ledger data

Testing Strategy:
□ Test with PQ algorithms when available
□ Performance testing with larger signatures
□ Integration testing with PQ wallets
□ Migration testing procedures

Documentation:
□ Document cryptographic dependencies
□ Plan user migration guides
□ Prepare FAQ for quantum questions
□ Track algorithm obsolescence

✅ Shor's algorithm is mathematically correct and would break ECC given a sufficient quantum computer. This isn't speculation—it's proven mathematics. The only question is when (not if) suitable quantum hardware will exist.

✅ Post-quantum cryptography standards exist and are ready for deployment. NIST has completed standardization. The algorithms are available. The transition can begin when platforms choose to implement them.

✅ XRPL's amendment process enables cryptographic migration. The protocol is designed to evolve. Adding post-quantum signature support is technically feasible through the established governance process.

⚠️ Timeline for cryptographically relevant quantum computers remains highly uncertain. Expert estimates range from 10 to 30+ years. Breakthroughs could accelerate or obstacles could delay.

⚠️ Specific quantum migration approach for XRPL hasn't been finalized. Which algorithms, what migration path, how to handle legacy accounts—these decisions haven't been made.

⚠️ Post-quantum cryptography is less battle-tested than current algorithms. ML-DSA has had years of analysis but hasn't protected trillions of dollars for a decade like ECC has.

🔴 Complacency based on "quantum computers are far away" thinking. Migration takes years. Starting too late could leave accounts vulnerable during the transition period.

🔴 Panic-driven decisions based on quantum FUD. The threat is real but not imminent. Scams exploiting quantum fear already exist. Rational planning beats reactive panic.

🔴 Assuming someone else will handle it. Users, developers, and institutions each have responsibilities. Waiting for others to solve the problem may leave you unprepared.

Quantum computing presents a genuine long-term threat to XRPL's current cryptography. The threat is not imminent—years to decades—but preparation should begin now.

The good news: solutions exist, XRPL can evolve, and there's time to prepare. The risk: complacency could result in rushed, error-prone migration when the threat becomes more urgent.

Rational response: stay informed, support protocol evolution toward post-quantum support, and be ready to migrate when the capability exists—well before quantum computers make it urgent.

Assignment: Create a quantum computing risk assessment for a hypothetical organization holding $10 million in XRP, including timeline analysis, vulnerability assessment, and migration planning.

Requirements:

• Current quantum computing state

• Timeline probability estimates

• "Harvest now, decrypt later" implications

• Organization-specific threat model

• XRPL account exposure assessment

• Cryptographic inventory

• Dependencies on vulnerable cryptography

• Comparative analysis with alternatives

• Post-quantum algorithm evaluation

• Migration approach options

• Timeline and milestones

• Resource requirements

• Dependencies on XRPL protocol evolution

• Probability-weighted scenarios

• Impact assessment per scenario

• Risk tolerance threshold

• Residual risk after mitigation

• Immediate actions (next 6 months)

• Short-term actions (1-2 years)

• Medium-term actions (3-5 years)

• Monitoring and triggers for escalation

• Technical accuracy (25%)

• Risk analysis quality (25%)

• Practical applicability (25%)

• Documentation completeness (25%)

Time Investment: 5-6 hours

Value: This assessment provides a template for organizational quantum risk planning and demonstrates systematic approach to emerging cryptographic threats.

For Next Lesson:
We'll examine cryptographic evolution and protocol agility—how XRPL can adapt its cryptographic foundations over time, the amendment process that enables evolution, and strategies for maintaining security as the cryptographic landscape changes.

End of Lesson 19

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