NIST PQC Standards and Implementation

NSA Commercial National Security Algorithm Suite 2.0:

Timeline Requirements:
├── 2025: Begin PQC transition planning
├── 2030: PQC capability required for new systems
├── 2033: All national security systems must be PQC
└── 2035: Complete deprecation of vulnerable algorithms

Algorithms Mandated:
├── ML-KEM-1024 (Level 5 only)
├── ML-DSA-87 (Level 5 only)
├── LMS/XMSS for firmware (hash-based, stateful)
└── Higher security levels than commercial

Implications:
├── Government contractors must comply
├── Sets floor for security expectations
├── Influences private sector adoption
└── XRPL should plan for similar timeline

Federal PQC Migration Requirements:

Key Mandates:
├── Inventory all cryptographic systems
├── Identify quantum-vulnerable systems
├── Prioritize migration of highest-risk systems
├── Complete migration by 2035

Priority Order:
├── 1. Systems protecting long-term secrets
├── 2. Critical infrastructure
├── 3. General purpose systems
└── Financial systems are high priority

XRPL Implications:
├── US-based XRPL businesses must comply
├── Exchanges, custodians affected
├── Likely accelerates XRPL PQC adoption
└── 2030-2033 deployment window likely

PQC Library Landscape (2024-2025):

Production-Ready:
├── liboqs (Open Quantum Safe): C library, most complete
├── PQClean: Reference implementations
├── BouncyCastle: Java/C# (PQC in development)
├── OpenSSL 3.x: PQC support emerging
└── AWS-LC: Amazon's library with PQC

Language-Specific:
├── Python: pqcrypto, liboqs-python
├── Rust: pqcrypto crate, oqs-rust
├── JavaScript/TypeScript: Limited, emerging
├── Go: cloudflare/circl
└── C++: liboqs (native)

XRPL-Specific (Future):
├── rippled: Will need PQC integration
├── xrpl.js: JavaScript library updates
├── xrpl-py: Python library updates
└── Timeline: Depends on XRPL amendment

Hardware Acceleration Status:

Current (2024):
├── Limited hardware support
├── Software implementations dominant
├── ARM/Intel optimizations available
└── HSMs: Limited PQC support

Near-Term (2025-2027):
├── HSM vendors adding PQC
├── Thales, Entrust, nCipher planning support
├── Hardware wallets: Limited announcements
├── Cloud HSMs: AWS/Azure/GCP adding support

XRPL Impact:
├── Software implementations sufficient initially
├── Hardware wallet support will lag
├── Enterprise custody may need HSM updates
└── Consumer wallets likely software-only initially

Hybrid Cryptography Rationale:

Definition:
├── Combine classical + PQC algorithms
├── Security: Valid if EITHER algorithm secure
├── Not "AND" — "OR" security model
└── Defense in depth

Motivation:
├── PQC algorithms less mature than classical
├── Unknown attacks may exist on PQC
├── Classical still secure against non-quantum
├── Hedge against both risks
└── Recommended during transition period

Example:
├── Sign with secp256k1 AND ML-DSA
├── Signature valid if both verify
├── If secp256k1 broken (quantum): ML-DSA protects
├── If ML-DSA broken (classical attack): secp256k1 protects
└── Size: Sum of both signatures

XRPL Hybrid Options:

Option 1: Dual Signatures
├── Every transaction has secp256k1 + ML-DSA signature
├── Both must verify for validity
├── Size: ~70 + 3,293 = ~3,363 bytes
├── Transition: Can verify old and new
└── Pro: Maximum security during transition

Option 2: Optional Hybrid
├── Users choose classical, PQC, or hybrid
├── Amendment enables choice
├── Size varies by choice
└── Pro: Flexibility for different risk profiles

Option 3: Transition Period
├── Initially require hybrid
├── After confidence period, allow PQC-only
├── Deprecate classical after quantum threat imminent
└── Pro: Phased approach, community confidence building

Recommendation:
├── Start with Option 2 (flexibility)
├── Encourage hybrid for high-value accounts
├── Move to PQC-only as confidence grows
└── Timeline: 5-10 year transition

Conformance Testing:

NIST Provides:
├── Known Answer Tests (KATs)
├── Test vectors for each parameter set
├── Input/output pairs to verify implementation
└── Essential for correct implementation

Validation Process:
├── Generate keys using test vectors
├── Sign test messages
├── Compare to expected signatures
├── Verify interoperability
└── Must match exactly

XRPL Testing:
├── Any PQC implementation must pass NIST tests
├── Additional blockchain-specific tests
├── Transaction signing test suite
├── Multi-sig combination tests
└── Performance benchmarks

Audit Requirements:

For XRPL PQC Implementation:
├── Code audit by cryptography experts
├── Side-channel analysis
├── Fuzzing and edge case testing
├── Formal verification (ideal)
└── Multi-auditor review recommended

Audit Focus Areas:
├── Random number generation
├── Key derivation correctness
├── Signature determinism
├── Memory handling (no leaks)
├── Timing consistency (side-channel)
└── Error handling

Timeline:
├── Implementation: 6-12 months
├── Internal testing: 2-3 months
├── External audits: 3-6 months
├── Bug fixes and re-audit: 2-3 months
└── Total: 12-24 months for production-ready

Proven: NIST standards are complete and well-defined; government mandates create adoption pressure; libraries exist.

Uncertain: Hardware support timeline; audit depth required; ecosystem upgrade coordination.

Risky: Implementing without audits; rushing adoption before tooling matures; ignoring hybrid option.

1. Which NIST standard defines digital signatures? Answer: FIPS 204 (ML-DSA)

2. NSA CNSA 2.0 requires PQC by: Answer: 2033 for national security systems

3. Hybrid cryptography provides security if: Answer: Either algorithm is secure (OR)

4. Most complete open-source PQC library: Answer: liboqs (Open Quantum Safe)

5. Why is hybrid recommended for transition? Answer: Hedges against unknown PQC attacks

End of Lesson 12