Xway: Post-Quantum Key Distribution Bridge

Executive Summary

Xway adds a post-quantum key encapsulation layer on top of XorIDA threshold sharing, creating channels that are both information-theoretically secure and quantum-resistant by construction.

XorIDA threshold sharing over GF(2) is already quantum-proof — it makes no computational assumptions. An attacker with infinite computing power learns nothing from K-1 shares. Xway adds a second layer: each share is XORed with a KEM-encapsulated shared secret and signed with a derived HMAC key.

The KEM layer is currently implemented as a bridge using AES-256-GCM. When Web Crypto API adds native ML-KEM support, only the internal wrapper changes. All calling code remains unchanged — same functions, same parameters, same wire format.

Use this when you need both information-theoretic security from XorIDA and post-quantum KEM protection for defense-in-depth, or when regulatory frameworks mandate NIST PQC compliance alongside unconditional security guarantees.

The Problem

Post-quantum cryptography standards are finalized, but Web Crypto API support is still years away. Organizations need quantum-safe channels now, not when browsers eventually ship native ML-KEM.

KEM latency is the bottleneck. ML-KEM-768 encapsulation adds ~2.7ms overhead per operation. For high-frequency trading, IoT telemetry, and real-time APIs, this latency is unacceptable. Traditional hybrid PQ KEM stacks (X25519 + ML-KEM) push total roundtrip time to 220ms for 1KB payloads.

Computational assumptions are fragile. ML-KEM security relies on lattice hardness (Module-LWE). If lattice assumptions break, all KEM-based systems fail instantly. Pure computational security offers no fallback.

Browser API timelines are unpredictable. Native Web Crypto ML-KEM support is not scheduled. Polyfills are large (hundreds of KB), slow, and add supply chain risk. Organizations building today cannot wait for standards bodies.

Migration risk is high. Hardcoding ML-KEM implementations means painful migrations when native support arrives. Every calling site needs updates. Wire formats break. Interoperability suffers.

The Solution

Xway wraps XorIDA shares with per-share KEM encapsulation and HMAC signatures. Two independent security layers: information-theoretic from XorIDA, computational from KEM. If either layer breaks, the other holds.

Double-Layer Pipeline

Layer 1: XorIDA splits the plaintext into K-of-N threshold shares over GF(2). This layer is unconditionally secure — no computational assumptions. An adversary with infinite compute power learns nothing from fewer than K shares.

Layer 2: Each share is encapsulated with an independent KEM operation. A fresh 256-bit shared secret is generated, encapsulated using the recipient's ML-KEM public key, expanded to the share length via HMAC-SHA256 counter mode, and XORed with the share. An HMAC-SHA256 signature derived from the shared secret protects integrity.

Create Pipeline

1. Validate config (totalShares, threshold, public key count)
2. PKCS#7 pad plaintext to 16-byte boundary
3. XorIDA split → K-of-N shares
4. For each share[i]:
   a. encapsulate(publicKey[i]) → (ciphertext, sharedSecret)
   b. expandSecret(sharedSecret, shareLength) → keyStream
   c. XOR share with keyStream → protectedShare
   d. deriveHmacKey(sharedSecret) → hmacKey
   e. signHMAC(protectedShare, hmacKey) → hmac
   f. package EncapsulatedShare(index, protectedShare, ciphertext, hmac)
5. Return QuantumChannelResult(channelId, shares[], algorithm)

Open Pipeline

1. Validate config and share count
2. For each encapsulatedShare[i]:
   a. decapsulate(ciphertext, privateKey[i]) → sharedSecret
   b. deriveHmacKey(sharedSecret) → hmacKey
   c. verifyHMAC(protectedShare, hmac, hmacKey)
   d. expandSecret(sharedSecret, shareLength) → keyStream
   e. XOR protectedShare with keyStream → recoveredShare
3. Collect K verified shares
4. XorIDA reconstruct from K shares → paddedPlaintext
5. PKCS#7 unpad → original plaintext

Real-World Use Cases

Six scenarios where double-layer quantum-safe channels provide regulatory compliance, defense-in-depth, or unconditional security guarantees.

Architecture

Xway is a pure library with zero npm dependencies. Three modules: types, KEM wrapper, and channel operations.

Double-Layer Security Model

Bridge Design

The KEM wrapper (kem-wrapper.ts) exposes three functions matching the ML-KEM standard interface:

Migration path: When Web Crypto API ships native ML-KEM, only kem-wrapper.ts internals change. All calling code in channel.ts remains identical. No wire format changes. No API surface changes. Zero-effort migration.

Integration

Xway integrates seamlessly with existing PRIVATE.ME ACIs. Use it anywhere you need double-layer quantum-safe protection.

Basic Integration

import {
  generateKemKeyPair,
  createQuantumChannel,
  openQuantumChannel
} from '@private.me/quantumchannel';

// Generate 3 key pairs (one per recipient)
const keys = await Promise.all([
  generateKemKeyPair('MLKEM768'),
  generateKemKeyPair('MLKEM768'),
  generateKemKeyPair('MLKEM768')
]);
const publicKeys = keys.map(k => k.value!.publicKey);
const privateKeys = keys.map(k => k.value!.privateKey);

// Create quantum channel (2-of-3 threshold)
const data = new TextEncoder().encode('Top secret message');
const config = {
  algorithm: 'MLKEM768',
  totalShares: 3,
  threshold: 2
};

const channel = await createQuantumChannel(data, config, publicKeys);

if (channel.ok) {
  // Reconstruct using any 2 shares
  const subset = channel.value.encapsulatedShares.slice(0, 2);
  const subKeys = privateKeys.slice(0, 2);
  const opened = await openQuantumChannel(subset, subKeys, config);

  if (opened.ok) {
    console.log(new TextDecoder().decode(opened.value));
    // "Top secret message"
  }
}

Cross-ACI Integration

Xway composes with other PRIVATE.ME building blocks:

Security

Xway provides two independent security layers. Both must fail simultaneously for total compromise.

Layer 1: Information-Theoretic (XorIDA)

XorIDA threshold sharing over GF(2) makes no computational assumptions. An adversary with infinite computing power learns nothing from fewer than K shares. This security property holds forever — there is no harvest-now-decrypt-later risk.

Layer 2: Computational (ML-KEM Bridge)

Each share is protected by an independent KEM operation. The current AES-256-GCM bridge provides computational security equivalent to AES-256. When native ML-KEM ships, security upgrades to NIST Security Level 3 (128-bit post-quantum) for ML-KEM-768 or Level 5 (256-bit post-quantum) for ML-KEM-1024.

HMAC Verification Before Reconstruction

Every share's HMAC is verified after decapsulation and before XorIDA reconstruction. A failed HMAC rejects the share entirely. Tampering is detected cryptographically, not heuristically.

Per-Share KEM Encapsulation

Each share uses an independent KEM operation with a fresh shared secret. Compromising one recipient's private key does not expose other shares. An attacker must compromise K distinct keys to reconstruct the plaintext.

No Math.random()

All randomness uses crypto.getRandomValues(). No weak PRNG. No predictable entropy sources.

Benchmarks

Xway overhead is dominated by XorIDA operations, not the KEM layer. The AES-256-GCM bridge adds negligible latency compared to pure XorIDA.

Comparison: Xway vs. Pure KEM Hybrid

Why Xway is faster: Hybrid PQ KEM stacks apply KEM to the entire payload. Xway applies KEM only to the XorIDA shares, which are smaller and processed in parallel. The AES-256-GCM bridge overhead (~0.5ms per share) is negligible compared to XorIDA split time.

Honest Limitations

Xway is not magic. It has known limitations. These are design constraints, not bugs.

1. Bridge Implementation Is Not Native ML-KEM

The current KEM wrapper uses AES-256-GCM, not true ML-KEM-768. Security is computational (AES-256) until Web Crypto API ships native ML-KEM. For applications requiring immediate NIST PQC compliance, this is a temporary limitation. The XorIDA layer still provides information-theoretic security.

2. No Key Rotation

KEM key pairs are static. If a private key is compromised, all shares encrypted to that key are vulnerable. Mitigation: use per-message ephemeral KEM keys (future enhancement) or rotate recipient identities entirely (new key pair = new identity).

3. No Forward Secrecy for KEM Layer

The current design does not provide per-share forward secrecy. If a recipient's private key is compromised, past shares encrypted to that key can be decrypted. The XorIDA layer still requires K shares, so single-key compromise does not fully break the channel. Future: integrate X25519 ECDH before KEM for per-share forward secrecy.

4. Larger Wire Format

Each EncapsulatedShare includes a KEM ciphertext (IV + AES-GCM encrypted secret, ~44 bytes) and an HMAC (32 bytes). For 2-of-3 channels, this adds ~228 bytes overhead (3 shares × 76 bytes). For bandwidth-constrained environments (satellite, LoRaWAN), this may be prohibitive.

5. Web Crypto API Dependency

Xway requires crypto.subtle for AES-GCM and HMAC-SHA256. This works in Node.js 20+, modern browsers, Deno, Bun, and Cloudflare Workers. It does not work in legacy environments (Node.js <15, IE11).

Roadmap

Xway is production-ready today as a bridge implementation. Native ML-KEM migration is planned for when Web Crypto API ships support.

Phase 1: Bridge Implementation (Current)

Status: Deployed. AES-256-GCM bridge provides computational security. XorIDA layer provides information-theoretic security. Zero npm dependencies. Full test coverage.

Phase 2: Native ML-KEM Migration (Planned)

Trigger: Web Crypto API ships crypto.subtle.generateKey('ML-KEM-768'). Only kem-wrapper.ts internals change. All calling code remains unchanged. Zero breaking changes for users.

Phase 3: Per-Share Forward Secrecy (Future)

Enhancement: Add X25519 ECDH before KEM encapsulation. Each share gets ephemeral key agreement + KEM wrapping. Compromised long-term keys do not expose past shares. Wire format change required.

Phase 4: Ephemeral KEM Keys (Future)

Enhancement: Generate per-message KEM key pairs instead of using static keys. Requires key distribution mechanism (via Xlink DID resolution or trust registry). Eliminates single-key compromise risk entirely.