Quantum-Proof Blockchain
Phase 1 Live — Phase 2 In ProgressKXCO Armature is a quantum-proof permissioned blockchain. Every transaction carries dual post-quantum signatures (ML-DSA-65 + SLH-DSA-SHAKE-128s), every block is independently attested with ML-DSA-65, and payloads are encrypted with ML-KEM-768. Built on the NIST FIPS 204 and FIPS 205 standards.
KXCO Armature was designed with post-quantum cryptography as a first-class requirement, not a retrofit. This page documents every cryptographic surface in the system, its quantum exposure, and the protection deployed against it — or the exact roadmap phase that closes it.
Quantum Coverage — 20 surfaces audited
16
Protected today
2
Actively mitigated
2
On defined roadmap
Green = live protection · Blue = deployed mitigation · Purple = committed roadmap
Complete Cryptographic Coverage Matrix
Every cryptographic surface in KXCO Armature — from transaction signing to backup encryption to entropy sources. No surface is undocumented, no gap is obscured.
| Layer | Surface | Threat | Status | Protection / Algorithm | Notes |
|---|---|---|---|---|---|
| Transaction | User transaction signing | High | Live | secp256k1 + ML-DSA-65 + SLH-DSA-SHAKE-128s (all three required) | Triple-algorithm: EVM compatibility + lattice PQC + hash-based PQC |
| Transaction | Transaction signing — algorithm diversity | High | Live | SLH-DSA-SHAKE-128s (FIPS 205) — hash-based, independent of lattice math | If lattice cryptography (ML-DSA) were broken, hash-based sig remains secure |
| Transaction | On-chain payment memo confidentiality | Low | Live | ML-KEM-768 + AES-256-GCM — encrypted in transaction data field | Only authenticated recipient can decrypt. Chain observers see opaque ciphertext. |
| Consensus | Block attestation (per block) | High | Live | ML-DSA-65 (FIPS 204) — all four validators | Independent PQC record of every finalised block |
| Consensus | Validator PQC key pairs | High | Live | ML-DSA-65 key pairs — generated at genesis | Ready for consensus activation; no new key ceremony needed |
| Consensus | Genesis PQC precompile reservation | High | Live | Reserved address 0x9 — permanent, cannot be reused | On-chain Dilithium3 verify precompile site locked in genesis |
| Consensus | QBFT consensus messages | High | Phase 2 | ML-DSA-65 activation — keys already in place | Network isolated + ML-DSA-65 attestation as interim control |
| Transport | External HTTPS/TLS (chain.kxco.ai) | Medium | Live | X25519MLKEM768 hybrid — TLS 1.3 key exchange | Hybrid: ML-KEM-768 + X25519 — quantum and classical resilient |
| Transport | Node-to-node P2P | High | Mitigated | Docker bridge isolated — ML-KEM-768 WireGuard PSK ready | No external party can harvest inter-node traffic |
| Account | EVM address / account model | High | Mitigated | PQCWallet.sol — ML-DSA-65 governs all fund operations | secp256k1 exposure confers zero authority over wallet assets |
| Storage | Wallet private keys (at rest) | Medium | Live | AES-256-GCM + Argon2id v3 (64 MB · 3 passes) | Memory-hard KDF resists GPU/ASIC brute-force. 128-bit quantum security (AES-256). |
| Storage | Database backups (at rest) | Medium | Live | AES-256-GCM — encrypted before leaving container | Plaintext copy deleted immediately after encryption |
| Integrity | Block history / chain state | Medium | Live | External checkpoint log (GitHub Gist) + ML-DSA-65 attestation | Forgery produces immediate detectable divergence |
| Integrity | Encrypted backup integrity signing | Medium | Live | SLH-DSA-SHAKE-128s (FIPS 205) signature on every encrypted backup file | Hash-based: verifiable by any third party holding the published public key. |
| Session | Authentication tokens | Low | Safe | HMAC-SHA-512 — 256-bit quantum security | Grover's gives at most 128-bit attack on SHA-512; 256-bit HMAC key doubles that |
| API | Institutional API authentication | Medium | Live | ML-DSA-65 per-request signatures (FIPS 204) — alternative to bearer tokens | Server stores only public key. No bearer token to steal or rotate. |
| Hash | EVM hash function (keccak256) | Low | Safe | keccak256 — 128-bit quantum preimage resistance | Grover's algorithm achieves √N speedup: 2^256 → 2^128 operations |
| Hash | Key derivation (Argon2id v3) | Low | Safe | Argon2id v3 — 64 MB, 3 passes. Legacy PBKDF2 paths silently upgraded on next use | Memory-hard. SHA-512: 2^256 quantum preimage. GPU parallelism defeated by memory cost. |
| Entropy | Key generation randomness | None | Safe | OS CSPRNG (crypto.randomBytes) | Quantum computers do not attack entropy sources |
| Infra | Docker image supply chain | Low | Roadmap | Cosign + ML-DSA-65 signing — Phase 5 | Images currently unsigned; supply chain hardening is Phase 5 |
What Is Quantum-Resistant Today
Every user transaction on KXCO Armature carries three signatures — secp256k1, ML-DSA-65, and SLH-DSA-SHAKE-128s. Every HTTPS connection uses hybrid post-quantum key exchange.Triple-algorithm signing (FIPS 204 lattice + FIPS 205 hash-based) means an adversary must break both independently — different mathematical foundations, no common failure mode. TLS key exchange uses X25519MLKEM768. Wallet private keys use AES-256-GCM with Argon2id v3 (memory-hard KDF, 64 MB). Optional payment memos are encrypted on-chain with ML-KEM-768 — only the recipient can read them.
| Component | Status | Detail |
|---|---|---|
| Triple-algorithm transaction signing (secp256k1 + ML-DSA-65 + SLH-DSA-SHAKE-128s) | Live | Every transaction carries three signatures: classical secp256k1 for EVM compatibility, CRYSTALS-Dilithium3 (ML-DSA-65, NIST FIPS 204) as the primary post-quantum signature, and SLH-DSA-SHAKE-128s (NIST FIPS 205) as a hash-based diversity hedge. All three are verified before mempool admission. ML-DSA and SLH-DSA rest on entirely different mathematical foundations — breaking lattice cryptography does not break hash-based cryptography. An adversary must defeat all three simultaneously. |
| ML-KEM-768 encrypted payment memos (on-chain) | Live | When both sender and recipient are on the KXCO platform, payment narratives (invoice references, settlement IDs, compliance codes) are encrypted with the recipient's ML-KEM-768 public key before being embedded in the transaction data field. The ML-KEM-768 shared secret derives a per-transfer AES-256-GCM key via HKDF-SHA-512. Chain observers see only opaque ciphertext; only the authenticated recipient can read the memo. |
| ML-DSA-65 per-block attestation (all four validators) | Live | Every finalised block receives four independent ML-DSA-65 signatures — one per validator — published to an external Gist. The canonical signed message is keccak256(chainId ‖ blockNumber ‖ blockHash). This creates a quantum-resistant chain-of-custody log for every block, independent of the consensus layer. |
| Validator ML-DSA-65 key pairs | Live | Dilithium3 key pairs were generated for all four validators at network genesis. Key material is held in isolated container storage alongside classical keys. Phase 2 consensus activation requires no new key generation — the key ceremony is already complete. |
| Genesis PQC precompile address reservation | Live | Address 0x0000000000000000000000000000000000000009 is reserved in the genesis block for the on-chain ML-DSA-65 verification precompile. This reservation is permanent and irrevocable — no contract can be deployed there before the precompile is activated. |
| Hybrid PQ-TLS — X25519MLKEM768 key exchange | Live | All HTTPS connections to chain.kxco.ai use TLS 1.3 with the X25519MLKEM768 hybrid named group as the preferred key exchange. This combines ML-KEM-768 (NIST FIPS 203 / Kyber) with X25519 — a quantum adversary must break both simultaneously to compromise the session. Clients that do not support hybrid PQ fall back to X25519. Verified on nginx 1.29.8 + OpenSSL 3.5.5. |
| Wallet private key encryption (AES-256-GCM + Argon2id v3) | Live | Every wallet private key is encrypted with AES-256-GCM before storage. Key derivation uses Argon2id v3 (PHC winner, memory-hard: 64 MB, 3 iterations, parallelism 1) with a random 32-byte salt and server-side pepper. Memory-hardness defeats GPU/ASIC parallel brute-force: each attempt must hold 64 MB for the full duration. AES-256 provides 128-bit quantum security. Existing v1/v2 (PBKDF2) keys are silently migrated to v3 on next transaction — no user action required. |
| Database backup encryption + SLH-DSA integrity signing | Live | Wallet database backups are encrypted with AES-256-GCM before leaving the container. The plaintext copy is deleted immediately after encryption. Each encrypted backup is additionally signed with SLH-DSA-SHAKE-128s (NIST FIPS 205) — a hash-based signature that proves the backup was produced by KXCO infrastructure. Any third party holding the published public key can verify the signature independently. |
| ML-DSA-65 per-request institutional API authentication | Live | Institutional API clients may authenticate using per-request ML-DSA-65 signatures instead of bearer tokens. The client generates a keypair locally, registers only the public key with a platform administrator, and signs each request with the private key (signed message: timestamp:METHOD:url). The server stores no secret — only the public key. This eliminates bearer token theft risk entirely and makes every request independently verifiable. |
| Session authentication (HMAC-SHA-512) | Safe | Session tokens use HMAC-SHA-512. Grover's algorithm provides at most a √N speedup against hash functions, reducing SHA-512 preimage security from 2^512 to 2^256 quantum operations — orders of magnitude beyond any foreseeable attack. HMAC-SHA-512 was deliberately selected over HMAC-SHA-256 for this reason. |
| Hash functions (keccak256, SHA-512) | Safe | The EVM uses keccak256 for all on-chain hashing. Grover's algorithm gives keccak256 a quantum preimage resistance of 2^128 operations — acceptable under NIST guidance (AES-128 equivalent). SHA-512 (used internally by Argon2id and HKDF) has 2^256 quantum preimage resistance. Neither function is threatened by any known quantum algorithm. |
| Key generation entropy (OS CSPRNG) | Safe | All key generation uses the operating system's cryptographically secure pseudorandom number generator (crypto.randomBytes in Node.js). Quantum computers do not attack entropy sources — CSPRNG security is not affected by quantum capability. |
What Is Not Yet Fully Quantum-Resistant
Honest disclosure: three attack surfaces use classical cryptography at the protocol layer and have defined roadmap phases to close them.All three have deployed mitigations in effect today that meaningfully reduce the practical risk. Two require protocol-level changes; one is an infrastructure hardening item. Publishing this table is a deliberate choice — any serious counterparty will ask, and partial migration is safer to acknowledge than to obscure.
| Attack Surface | Classical Layer | Residual Risk | Deployed Mitigation | Full Cryptographic Close |
|---|---|---|---|---|
Validator consensus messages Network Isolated + PQC Attested | ECDSA secp256k1 | A quantum adversary could forge consensus votes to manipulate finality. Requires server-level access — consensus traffic is inaccessible externally. | Consensus traffic is isolated on Docker bridge (172.20.0.0/24); P2P ports bound to localhost. Every finalised block carries four independent ML-DSA-65 attestations — a quantum-forged consensus message cannot produce valid Dilithium3 attestations, making the attack immediately detectable. | Phase 2 — ML-DSA-65 signing of QBFT consensus messages at the protocol level. Dilithium3 key material is already generated and stored; activation is a software upgrade, not a key ceremony. |
Node-to-node P2P transport Network Isolated + PQ-VPN Ready | Classical TLS (ECDH) | Harvest-now-decrypt-later on classical ECDH. On the current single-server deployment, all inter-node traffic is on the Docker bridge and cannot be harvested externally — there is no traffic for an adversary to record. | Docker bridge isolation + localhost-only P2P ports. For multi-server deployment, a WireGuard overlay with ML-KEM-768 (NIST FIPS 203 / Kyber) derived preshared keys is generated and ready — this wraps ECDH with a post-quantum symmetric layer, neutralising harvest-now-decrypt-later even if Curve25519 is later broken. | Phase 3 — ML-KEM-768 replaces ECDH natively in the Besu node transport layer. |
Docker image supply chain Unsigned — Phase 5 | Unsigned Docker images | A supply chain compromise could substitute a malicious image without detection. Low probability in the current controlled deployment; becomes material as the validator set expands to independent operators. | Images are pulled from the Docker Hub official registry (hyperledger/besu) with pinned version tags. The build environment is controlled — no automated pipeline pushes to production. Multi-operator deployment increases this risk. | Phase 5 — Cosign + ML-DSA-65 signing of all production Docker images, with mandatory signature verification before container start. |
Peer comparison
Same attack surfaces — how major chains respond
Bitcoin, Ethereum, and Solana share these attack surfaces. None has deployed mitigations. On public permissionless networks, the P2P harvest-now-decrypt-later attack is actively feasible today — anyone can connect and record encrypted traffic. KXCO Armature's P2P is inaccessible to external parties.
| Attack Surface | Bitcoin | Ethereum | Solana | KXCO Armature |
|---|---|---|---|---|
| Consensus / validator signing | PoW — no signing No consensus signatures; PoW-based finality. All node communication is classical and public. | BLS12-381 (classical) Validator attestations use classical BLS aggregate signatures. No PQC. Open network — traffic is harvestable. | Ed25519 (classical) Vote transactions signed with Ed25519. No PQC. Open network. | ECDSA + Dilithium3 attested Classical ECDSA for protocol consensus; every finalised block additionally carries four independent ML-DSA-65 signatures from all validators. Network isolated — not externally reachable. |
| Node-to-node P2P transport | TCP / ECDH (v2) Bitcoin v2 P2P adds classical ECDH encryption. No PQC. Fully public — any party can connect and harvest traffic today. | libp2p/Noise — X25519 Classical X25519 ECDH key exchange. No PQC. Fully public network — harvest-now-decrypt-later is actively feasible. | QUIC/TLS 1.3 — ECDH Classical ECDH in TLS 1.3. No PQC. Fully public — any party can harvest encrypted traffic. | Classical TLS — network isolated All P2P runs on a private Docker bridge (172.20.0.0/24). No external traffic to harvest. ML-KEM-768 WireGuard PSK layer prepared for multi-server deployment. |
| External HTTPS / API transport | Classical TLS 1.3 Classical ECDH (X25519). No hybrid PQ. Harvest-now-decrypt-later on all API traffic. | Classical TLS 1.3 No PQ-TLS on any major Ethereum endpoint. X25519 only. | Classical TLS 1.3 No hybrid PQ-TLS deployed. | X25519MLKEM768 hybrid TLS TLS 1.3 with X25519MLKEM768 as the preferred named group. Hybrid: must break both ML-KEM-768 and X25519 simultaneously to compromise the session key. |
| Account / address model | HASH160(secp256k1) Public key revealed on first spend. No PQC accounts or migration path deployed. | keccak256(secp256k1) Public key revealed on first spend. EIP-4337 account abstraction exists but no PQC wallet standard is deployed or scheduled. | Ed25519 pubkey = address The public key is directly the account address — exposed on every transaction. Worst-case quantum exposure of any major chain. | PQCWallet (ML-DSA-65) Institutional accounts use PQCWallet governed by ML-DSA-65. secp256k1 exposure confers zero authority over wallet assets. Migrates to on-chain precompile at Phase 3 with no fund movement. |
| Private key / data at rest | Application-dependent No protocol-level specification. Most wallets use AES-256 if they encrypt at all. | Application-dependent Keystore format (EIP-55) uses AES-128-CTR with PBKDF2 or scrypt. AES-128 has only 64-bit quantum security — below NIST minimum. | Application-dependent No protocol-level encryption standard for stored keys. | AES-256-GCM + Argon2id v3 Wallet private keys encrypted with AES-256-GCM and Argon2id v3 (memory-hard: 64 MB, 3 passes). AES-256: 128-bit quantum security. Argon2id defeats GPU/ASIC parallelism. Note: Ethereum keystore format uses AES-128 — insufficient under NIST guidance. |
| Deployed PQC mitigations (total) | None No committed roadmap. | None No formal EIP or committed timeline for base-layer PQC. | None No public PQC roadmap. | All high-risk surfaces mitigated 18 of 21 surfaces protected today. Triple-algorithm tx signing (ML-DSA-65 + SLH-DSA-SHAKE-128s + secp256k1), ML-KEM encrypted memos, Argon2id v3 KDF, SLH-DSA backup signing, ML-DSA API auth, hybrid PQ-TLS, PQCWallet, and external checkpointing all live. |
Implementation Specifics
The following details address the questions a cryptographic peer would ask before accepting our implementation claims.
ML-DSA-65 (Dilithium3) Parameters
| Algorithm | CRYSTALS-Dilithium3 (ML-DSA-65) |
| Standard | NIST FIPS 204, August 2024 |
| Security level | NIST Level 3 ≈ AES-192 |
| Mathematical basis | Module Lattice (MLWE + MSIS) |
| Public key size | 1,952 bytes |
| Signature size | 3,309 bytes |
| Resistant to | Shor's algorithm, Grover's algorithm |
ML-KEM-768 (Kyber) — TLS Key Exchange
| Algorithm | ML-KEM-768 (Kyber768) |
| Standard | NIST FIPS 203, August 2024 |
| Security level | NIST Level 3 ≈ AES-192 |
| Mathematical basis | Module Lattice (MLWE) |
| TLS group name | X25519MLKEM768 (hybrid) |
| Deployment | nginx 1.29.8 + OpenSSL 3.5.5 |
| Fallback | X25519 for non-PQ clients |
Triple-Algorithm Transaction Signing
| Signing model | Triple — all three signatures required |
| Classical sig | secp256k1 ECDSA (EVM compatibility) |
| PQC sig 1 | ML-DSA-65 — lattice-based (FIPS 204) |
| PQC sig 2 | SLH-DSA-SHAKE-128s — hash-based (FIPS 205) |
| Algorithm diversity | Lattice + Hash — different math, no common failure |
| Verification | Node-level — enforced before mempool admission |
| Key derivation | HKDF-SHA-512 from secp256k1 key (domain-separated) |
Symmetric & Key Derivation Layer
| Private key encryption | AES-256-GCM |
| Backup encryption | AES-256-GCM |
| KDF (current v3) | Argon2id — 64 MB, 3 passes, parallelism 1 |
| KDF (legacy v1/v2) | PBKDF2-SHA-256 / PBKDF2-SHA-512 — auto-upgraded |
| Salt | 32 bytes random per key |
| Server pepper | Additional secret in environment |
| Memory zeroization | Derived AES key Buffer.fill(0) after use |
| Session MAC | HMAC-SHA-512 |
| Quantum security | 128-bit (AES-256) / 256-bit (SHA-512) |
SLH-DSA-SHAKE-128s Parameters
| Algorithm | SPHINCS+-SHAKE-128s (SLH-DSA) |
| Standard | NIST FIPS 205, August 2024 |
| Security level | NIST Level 1 ≈ AES-128 |
| Mathematical basis | Hash functions (SHA-3 / SHAKE) only |
| Public key size | 32 bytes |
| Signature size | 7,856 bytes |
| Why deployed | Algorithm diversity: different math from ML-DSA |
ML-KEM-768 Encrypted Memos
| Encapsulation | ML-KEM-768 (NIST FIPS 203) |
| Memo encryption | AES-256-GCM, fresh IV per transfer |
| Key derivation | HKDF-SHA-512 from secp256k1 key |
| Data location | Transaction data field (on-chain, immutable) |
| Format | KXCOMEMO header + KEM ciphertext + IV + tag + ciphertext |
| Decryption | Server-side, on authenticated request only |
| Observer view | Opaque ciphertext — memo content not visible |
Why Level 3 (Dilithium3) and not Level 5 (Dilithium5)?Dilithium5 increases the signature size to 4,595 bytes, adding approximately 40% overhead versus Dilithium3. For a private permissioned network with a known and controlled validator set, NIST Level 3 provides a security margin that materially exceeds any foreseeable quantum attack capability. This follows NIST's own published guidance that Level 3 is appropriate for most production infrastructure. Level 5 is available as a configurable upgrade if the threat model changes.
Why X25519MLKEM768 (hybrid) for TLS rather than pure ML-KEM?The hybrid approach ensures security against both classical and quantum adversaries simultaneously. If ML-KEM-768 has an undiscovered vulnerability, X25519 still protects the session. If X25519 is broken by a quantum computer, ML-KEM-768 still protects it. Both must be broken simultaneously. This follows the IETF hybrid PQ recommendation (draft-ietf-tls-hybrid-design) and NIST's own migration guidance. OpenSSL 3.2+ supports X25519MLKEM768 natively.
Roadmap to Full Quantum Resistance
The roadmap defines what "fully quantum-resistant" means for KXCO Armature and the concrete steps to achieve it. Each phase closes a specific residual gap identified in the tables above.
Phase 1 — Complete
PQC Foundation, Triple-Algorithm Signing & Infrastructure Hardening
Surfaces closed: transaction signing (triple-algorithm), block attestation, key pairs, TLS transport, private key encryption, backup encryption + signing, encrypted memos, ML-DSA API auth
- Dilithium3 key pairs generated for all validators at network genesis — no key ceremony needed for later phases
- Triple-algorithm transaction signing: secp256k1 + ML-DSA-65 + SLH-DSA-SHAKE-128s — all three required before mempool admission
- Per-block ML-DSA-65 attestation published to external Gist — quantum-resistant chain-of-custody for every block
- Genesis block reserves address 0x9 for on-chain Dilithium3 verification precompile — permanent reservation
- Hybrid PQ-TLS enabled: X25519MLKEM768 on all HTTPS endpoints via nginx 1.29.8 + OpenSSL 3.5.5
- Wallet private key encryption: AES-256-GCM + Argon2id v3 (64 MB · 3 passes) — memory-hard, silent migration from PBKDF2 on next use
- ML-KEM-768 encrypted payment memos: recipient-only on-chain confidentiality via FIPS 203 key encapsulation
- Database backup encryption: AES-256-GCM + SLH-DSA-SHAKE-128s integrity signature — hash-based, third-party verifiable
- ML-DSA-65 per-request institutional API authentication: server stores only public key, no bearer token required
Phase 2 — In Progress
PQC Consensus Layer — QBFT Validator Signing
Surface closed: validator consensus messages
- All QBFT consensus messages (proposals, votes, commits) signed with Dilithium3 in addition to classical key
- No new key generation required — Dilithium3 keys from Phase 1 are activated for consensus use
- Dual-signing transition: both classical and PQC signatures required during migration window, then classical retired
- Coordinated upgrade across all four validators — executed as scheduled maintenance
Phase 3 — Planned
Native PQC Transport, Transaction Type & On-Chain Precompile
Surfaces closed: P2P transport (protocol-level), EVM account model (protocol-level), on-chain verification
- ML-KEM-768 replaces ECDH in node-to-node TLS at the Besu protocol layer — eliminates harvest-now-decrypt-later residual on P2P
- Native Dilithium3 transaction type promoted from application layer to protocol layer
- On-chain Dilithium3 verification precompile deployed at reserved genesis address 0x9 — smart contracts verify PQC signatures without EVM loop overhead
- Dilithium3-derived address scheme — new accounts use PQC-derived addresses by default
- Existing accounts: migration tooling provides balance continuity path to PQC-derived addresses
Phase 4 — Planned
Classical Signing Retirement — Full PQC Operation
Result: all active signing operations are quantum-resistant at the protocol level
- Classical secp256k1 transaction signing disabled at protocol level after migration window closes
- Network operates entirely on Dilithium3 for all active signing operations
- Classical keys retained for historical signature verification (read-only)
- As a private permissioned network, KXCO Armature executes this upgrade by validator governance vote — no contentious hard fork
Phase 5 — Planned
Supply Chain Hardening — PQC-Signed Docker Images
Surface closed: Docker image supply chain
- All production Docker images signed with ML-DSA-65 via Sigstore/Cosign
- Mandatory signature verification before container start — invalid signatures block deployment
- Validator operator onboarding includes public key registration for supply chain trust chain
PQC Readiness — KXCO Armature vs Major Blockchain Networks
As of 2026, no major public blockchain has deployed production post-quantum transaction signing or hybrid PQ-TLS. KXCO Armature is in a distinct category: PQC is operational across multiple layers, not planned.
| Network | Classical Signing | PQC Tx Signing | PQC Consensus | Hybrid PQ-TLS | Roadmap |
|---|---|---|---|---|---|
| KXCO Armature | secp256k1 ECDSA | Live | Phase 2 | Live | Active — 5-phase plan, Phase 1 complete |
| Bitcoin | secp256k1 ECDSA / Schnorr | None | None | None | No formal roadmap. BIP discussions exist; no consensus. |
| Ethereum | secp256k1 ECDSA | None | None | None | No formal standard or committed timeline. EIP-4337 could support PQC wallets as an application layer; no base-layer implementation is scheduled. |
| Solana | Ed25519 | None | None | None | No public roadmap. |
| XRP Ledger | secp256k1 / Ed25519 | None | None | None | Exploratory discussion only. No committed implementation. |
| Hedera | secp256k1 / Ed25519 | None | None | None | Community discussion. No formal proposal. |
Why public chains lag on PQCPublic blockchains require social consensus across thousands of independent stakeholders to change cryptographic primitives — a process that takes years and often fails. KXCO Armature's permissioned architecture means a quantum upgrade is a scheduled maintenance event coordinated across a known validator set. The key material is already in place. Activation requires governance vote, not a contentious hard fork. Hybrid PQ-TLS requires only an nginx configuration change and a supported OpenSSL version — both already satisfied.
Design Principles — Why This Architecture
Harvest-Now-Decrypt-Later
Nation-state adversaries are known to record encrypted traffic today for decryption when quantum capability matures. This applies to TLS sessions, inter-node P2P traffic, and any encrypted communication. KXCO Armature addresses this at every layer: hybrid PQ-TLS for external traffic, network isolation for P2P, AES-256 for stored data.
No Proprietary Cryptography
KXCO Armature uses only NIST-standardised algorithms. CRYSTALS-Dilithium3 and Kyber underwent six years of public cryptanalysis as part of the NIST PQC competition. The hybrid TLS group X25519MLKEM768 follows the IETF hybrid design draft. No custom, unreviewed, or "quantum-resistant by claim" schemes are employed anywhere in the stack.
Hybrid Transitional Security
Every PQC deployment on KXCO Armature uses a hybrid model during the transition: transaction signing requires both secp256k1 and ML-DSA-65; TLS uses both X25519 and ML-KEM-768. An adversary must break both the classical and post-quantum component simultaneously. This provides forward security even if either component has an undiscovered vulnerability.
Accelerated Response Capability
All PQC key material was generated at genesis. The TLS upgrade required only a configuration change. The migration path is pre-planned and pre-tested. A credible quantum timeline compression does not require emergency key generation, network redesign, or stakeholder consensus — the infrastructure is ready to accelerate.
Symmetric Safety Margin
AES-256 was deliberately chosen over AES-128 because Grover's algorithm halves symmetric key security in the quantum setting: AES-128 provides only 64-bit quantum security, below NIST's 128-bit minimum. AES-256 provides 128-bit quantum security. Argon2id v3 (memory-hard: 64 MB, 3 passes) was chosen over PBKDF2 for key derivation — its memory cost defeats GPU/ASIC parallel attacks that PBKDF2 cannot resist. Note: Ethereum's keystore format uses AES-128-CTR + PBKDF2 — insufficient on both counts under NIST guidance.
No Public Mempool Exposure
Transactions are not broadcast to a public network before inclusion. The window in which an adversary could observe a pending transaction's public key before it is mined — a known attack vector on public chains — does not exist on KXCO Armature. This eliminates a class of quantum timing attacks that are genuinely feasible against Bitcoin and Ethereum today.
Standards & Regulatory References
| Standard | Body | Published | Relevance to KXCO Armature |
|---|---|---|---|
| FIPS 204 — ML-DSA (Dilithium) | NIST | Aug 2024 | Primary signature algorithm — deployed in production for transaction signing and block attestation |
| FIPS 203 — ML-KEM (Kyber) | NIST | Aug 2024 | Key encapsulation — deployed in X25519MLKEM768 TLS hybrid; targeted for Phase 3 P2P transport layer |
| FIPS 205 — SLH-DSA (SPHINCS+) | NIST | Aug 2024 | Deployed — SLH-DSA-SHAKE-128s used as second PQ transaction signature (algorithm diversity hedge) and backup integrity signing |
| IETF draft-ietf-tls-hybrid-design | IETF TLS WG | 2024 | Hybrid post-quantum TLS key exchange design — basis for X25519MLKEM768 implementation |
| NSA CNSA 2.0 | NSA / CISA | Sep 2022 | US government mandate: PQC migration complete by 2035 for national security systems |
| BSI TR-02102-1 | BSI (Germany) | 2024 | German federal guidance on cryptographic algorithms — Dilithium3 and AES-256 compliant |
| ENISA PQC Report | ENISA (EU) | 2022 | European cybersecurity agency PQC migration guidance for critical infrastructure |
| MAS TRM Guidelines | MAS (Singapore) | 2021 | Monetary Authority of Singapore technology risk framework — cryptographic agility requirement |
Technical enquiries
For implementation specifications, cryptographic audit requests, or integration questions, contact the KXCO Armature engineering team.