Wallet Security Architecture
NIST FIPS 203 / 204 / 205This page documents the cryptographic controls protecting every account on the KXCO Institutional platform — from private key storage through to transaction submission. All claims are derived directly from deployed code.
Private Key Protection
Private keys are encrypted server-side before the database row is written and are never transmitted to the client. Decryption occurs only within the server process, for the duration of transaction signing, and the derived key buffer is explicitly zeroed after use.
| Cipher | AES-256-GCM | 128-bit quantum security. Grover's algorithm halves AES key strength — AES-256 → 128-bit. Above NIST minimum. |
| Key derivation | Argon2id (v3) | Memory-hard: 64 MB, 3 iterations, parallelism 1. Resistant to GPU/ASIC parallel attacks. Significantly stronger than PBKDF2 against offline brute-force. |
| KDF cost | 64 MB · 3 passes | Each hash attempt requires holding 64 MB for the full duration. GPU farms cannot parallelise cheaply — attack cost scales with memory, not just compute. |
| Salt | 32 bytes (random per key) | Generated via OS CSPRNG. Unique per wallet — rainbow tables are infeasible. |
| Server pepper | Env-injected secret | Combined with the user password before KDF. A full database leak without the pepper cannot produce offline dictionary attacks. |
| Memory zeroization | Explicit Buffer.fill(0) | The 32-byte derived AES key is zeroed immediately after use. Reduces exposure window for in-memory key material. |
| Admin recovery layer | AES-256-GCM (separate key) | Independent encryption under WALLET_ADMIN_KEY. Password reset does not require the original password. |
| KDF versioning | v3 (Argon2id, current) | v1=PBKDF2-SHA-256, v2=PBKDF2-SHA-512. Existing keys silently upgraded to v3 on next transaction. No user action required. |
Comparison — Ethereum keystore format (EIP-55)The standard Ethereum keystore uses AES-128-CTR with PBKDF2 or scrypt. AES-128 provides only 64-bit quantum security — below NIST's 128-bit minimum. PBKDF2 is not memory-hard and can be parallelised on GPUs. KXCO Institutional uses AES-256-GCM + Argon2id throughout.
Transaction Signing — Post-Quantum
Every transaction carries two signatures embedded in the transaction data field: a classical secp256k1 signature for EVM compatibility, and a lattice-based ML-DSA-65 post-quantum signature. The ML-DSA keypair is derived deterministically from the secp256k1 private key via HKDF — no additional key material is stored.
| Classical signature | secp256k1 ECDSA | Retained for EVM compatibility. The secp256k1 signature covers the full transaction including PQ data. |
| PQ signature | ML-DSA-65 (Dilithium3) | NIST FIPS 204. Security Level 3 ≈ AES-192. Mathematical basis: Module Lattice (MLWE + MSIS). Quantum-resistant. |
| Key derivation | HKDF-SHA-512 from secp256k1 key | ML-DSA seed derived deterministically from the secp256k1 private key via domain-separated HKDF. No additional key storage required. |
| Signed message | KeccakHash(chainId‖to‖value‖nonce‖gasPrice) | Commits to the full transaction intent without the data field (which contains the signatures themselves). |
| Signing location | Server-side only | Keys are decrypted, used to sign, and zeroed — all within the server process. Never transmitted to the client. |
ML-KEM Encrypted Transaction Memos
Transfers may include an optional payment narrative (invoice reference, settlement ID, compliance code). When both parties are on the KXCO platform, the memo is encrypted with the recipient's ML-KEM-768 public key before being embedded in the transaction data field. External chain observers cannot read it.
| Key encapsulation | ML-KEM-768 (Kyber768) | NIST FIPS 203. Each transfer encapsulates a fresh shared secret under the recipient's ML-KEM-768 public key. |
| Memo encryption | AES-256-GCM | Shared secret → 256-bit symmetric key. Fresh IV per memo. Auth tag provides tamper detection. |
| Key derivation | HKDF-SHA-512 from secp256k1 key | ML-KEM keypair derived deterministically. Public key is stored and published; private key derived on demand. |
| Data location | Transaction data field (on-chain) | Format: KXCOPQ01 header + ML-KEM ciphertext + IV + tag + encrypted memo. Immutable and verifiable. |
| Decryption | Server-side on authenticated request | The custodial server decrypts on behalf of the authenticated account holder. Key never leaves server. |
Transport Security — Hybrid PQ-TLS
All connections use TLS 1.3 with X25519MLKEM768 as the preferred key exchange. An adversary must break both ML-KEM-768 and X25519 simultaneously to compromise the session key.
| TLS named group | X25519MLKEM768 | Hybrid: ML-KEM-768 (NIST FIPS 203) + X25519. Preferred group in TLS 1.3 ClientHello. |
| Fallback | X25519 | Clients that do not support hybrid PQ fall back to classical X25519. |
| Implementation | nginx 1.29.8 + OpenSSL 3.5.6 | X25519MLKEM768 is natively supported. nginx config sets ssl_ecdh_curve X25519MLKEM768:X25519; — PQ group preferred, classical fallback. |
| Protocol | TLS 1.3 (TLS 1.2 allowed) | TLS 1.0 and 1.1 disabled. HSTS 2-year preload enforced. |
| Session tickets | Disabled | Prevents session resumption attacks. Fresh key exchange on every connection. |
Harvest-now-decrypt-laterNation-state adversaries record encrypted traffic today for decryption once quantum capability matures. Hybrid PQ-TLS eliminates this risk — the session key cannot be recovered even if X25519 is later broken.
Webhook Identity — Hybrid PQ Signatures
Every outbound webhook is signed twice: once with a per-institution HMAC-SHA-256 secret for backwards compatibility, and once with the platform's ML-DSA-65 (NIST FIPS 204) private key. Receivers fetch the platform public key from a well-known endpoint, pin it, and verify each delivery offline.
| Classical signature | HMAC-SHA-256 | Per-institution shared secret. Symmetric, quantum-safe, but does not give non-repudiation if the secret leaks. |
| PQ signature | ML-DSA-65 (Dilithium3) | NIST FIPS 204. Binds the message to the platform identity cryptographically. Survives leakage of the per-institution HMAC secret. |
| Signed message | `${timestamp}.${raw_body}` | Both signatures cover exactly the same envelope so receivers can verify either independently. |
| Platform key derivation | HKDF-SHA-512 from KXCO_KEY_MASTER | Deterministic. Same private key across replicas, no DB row, never leaves the process. |
| Discovery endpoint | /wallet/api/.well-known/kxco-pq-pubkey | Returns publicKey (3904 hex chars), algorithm, spec, kid fingerprint, and message format. Cache-Control: public, max-age=3600. |
| Key identifier (kid) | SHA-256(pubkey)[:16] | 16-hex-char fingerprint. Receivers compare against the pinned kid before verifying — fast rejection of stale or unknown keys. |
| Headers on delivery | X-KXCO-PQ-Signature + X-KXCO-PQ-Kid | In addition to the existing X-KXCO-Signature (HMAC) and X-KXCO-Timestamp headers. |
Why hybrid?HMAC-SHA-256 is post-quantum secure as a MAC — Grover's algorithm offers only a square-root speedup and 256-bit keys leave 128 bits of effective strength. What HMAC cannot provide is non-repudiation: any party who knows the shared secret can forge a signature. ML-DSA-65 closes that gap. A receiver who verifies the PQ signature is mathematically certain the message came from the KXCO platform — not from a compromised receiver, not from a leaked shared secret.
Session & Authentication Security
| Session mechanism | iron-session (AES-256-GCM) | Session data is sealed server-side. The cookie contains only an encrypted, authenticated token. |
| Cookie flags | httpOnly · secure · sameSite=strict | JavaScript cannot read the session cookie. Only transmitted over HTTPS. CSRF blocked. |
| Session lifetime | 7 days | Re-validated against the database on every protected request — suspended accounts are locked out immediately. |
| API key storage | SHA-256 hash only | Raw bearer token shown once at creation. Only the hash is stored. |
| ML-DSA API auth | Per-request signed (ML-DSA-65) | Alternative to bearer tokens. Client holds ML-DSA private key; server stores only the public key. Eliminates bearer token theft risk. |
| Password storage | bcrypt (cost 12) | User passwords are never stored — only the bcrypt hash. |
| Login brute-force | Account lock on repeated failure | Failed attempts counted; account locked after threshold. |
Standards Compliance
| NIST FIPS 204 | ML-DSA-65 (Dilithium3) | Transaction signing. Published August 2024. |
| NIST FIPS 203 | ML-KEM-768 (Kyber768) | TLS key exchange (X25519MLKEM768) and encrypted memo encapsulation. Published August 2024. |
| NIST SP 800-132 | PBKDF2 guidance | KDF iterations and salt length exceed recommended minimums (legacy path). |
| Argon2id | Password Hashing Competition winner | Memory-hard KDF. Current v3 standard on this platform. |
| NSA CNSA 2.0 | AES-256 + ML-DSA | Both the symmetric and asymmetric algorithms are on the CNSA 2.0 approved list. |
| IETF hybrid TLS draft | draft-ietf-tls-hybrid-design | Basis for X25519MLKEM768 deployment. |
For cryptographic audit requests, implementation specifications, or institutional due diligence enquiries, contact the KXCO engineering team.