A post-quantum key encapsulation gateway built on ℤ₆ cyclic topology. Key exchange uses HKDF-SHA256 + AES-256-GCM with no lattice, no NTT, and no isogenies — just 64-element Z6 keys packed into 24 bytes, validated in constant time at the edge.
The Z6 PQC Gateway replaces continuous lattice-based KEMs with discrete ℤ₆ arithmetic. Each element is a phase in {0,1,2,3,4,5} — no floating point, no noise sampling, no NTT polynomial multiplication.
All operations are mod-6: add, subtract, multiply in ℤ₆. Deterministic, constant-time, trivially side-channel resistant. No continuous parameters to leak.
Phase states are projected onto the nearest Z6 lattice point. Noise within ±π/6 is absorbed; noise at the π/6 boundary triggers an enforced collapse — detectable, non-forgeable.
All ephemeral key material is zeroed immediately after use. Private keys, shared secrets, and intermediate buffers are overwritten in a finally block — guaranteed cleanup.
Run a complete key encapsulation cycle in your browser. Client and server generate ℤ₆ key pairs, negotiate a shared secret, and the topological shield validates every step.
The Z6 topological shield enforces phase quantization at every gateway hop. No active error correction — just geometry.
Every Z6 element is projected to the nearest multiple of π/3. Deviation beyond ±π/6 triggers a detectable topological collapse.
At the exact midpoint between two Z6 states (deviation = π/6), the shield rejects the operation with a 403 — no ambiguity, no false acceptance.
Shield projection uses integer rounding — no branches on secret data. The validation cost is identical for all 6 phase states.
The shield adds no per-request latency, no memory allocation, and no additional network round-trips. It runs inline in the Worker's fetch handler.
This is a live security research interface. Submit crafted public keys to the gateway and see which defenses trigger. All attacks are logged as anonymous metrics — no key data is stored. Can you find a key that passes every check?
Quick-craft attack vectors to probe the shield:
Paste a base64url-encoded public key (24 bytes) or leave empty to generate random:
Only attack type, danger score, and which checks triggered are stored locally. No key data is ever saved.
The Z6 topological moat was tested across IBM and IonQ quantum processors. Results confirm that ℤ₆ phase quantization absorbs ZZ crosstalk and preserves multi-qubit entanglement under spatial isolation.
IBM Heron R2 (ibm_fez) demonstrated 95.2% average GHZ fidelity and 98.44% peak using the Z6 moat protocol. The spatial buffer (distance-2+ isolation) absorbs ZZ parasitic coupling without dynamical decoupling overhead.
IonQ Forte-1 validated the Z6 moat on trapped-ion hardware. Bell state fidelity: 97.9%. 4-qubit GHZ: 96.0%. The moat protocol is hardware-agnostic — no trapped-ion specific calibration required.
Z6 parity invariants are formally derived in Lean4 (ParityKernelV6). The kernel proves that ℤ₆ phase closure is a topological invariant — no empirical constants imported. All SM parameter derivations are kernel-native.
Systematic bus validation (Phases 2-6) showed dynamical decoupling ineffective (49.2%→49.8%), strict time-binning also ineffective (48.9%→48.6%). Only spatial moat isolation (distance-2+ buffer) restored coherence to 90.5-91.1%.
Every component is self-contained. No external dependencies, no hardware assumptions, no trusted setup.
Mod-6 arithmetic (add, sub, mul) and continuous-to-discrete phase mapping. Every real angle is snapped to the nearest π/3 step with a bounded deviation.
Each Z6 element fits in 3 bits (values 0-5). 64 elements pack into 24 bytes. Serialization is a single O(n) bit-shift loop — no alloc, no compression.
Client and server exchange ℤ₆ public keys. Shared secret is wrapped with HKDF-SHA256 + AES-256-GCM — context-bound to the server public key. NIST-standard, constant-time, memory-scrubbed.
In the finally block of every request, all Uint8Array and number[] buffers are filled with zero. No ephemeral key material survives past the response.
Every property of the Z6 PQC gateway is verified — arithmetic, packing, topological shield, key agreement, and memory safety.
Make a real request to the Z6 PQC Gateway, verify the topological shield header, and perform a live KEM handshake.
Use the KEM shared secret to derive an AES-256-GCM key and encrypt/decrypt messages. Your Z6 public key serves as the identity.
Generate shared secrets for multiple public keys in a single request (one per line):
Quantum-safe ℤ₆ topology + classical HKDF-SHA256/AES-256-GCM. Deploy to your own Cloudflare account. No external dependencies, no third-party APIs.
Live measurements against this production gateway running v4.0.0. Reproducible harness; no modelled or projected figures.
A stateless public endpoint must decide whether to spend a post-quantum decapsulation on an incoming request. The ℤ6 admission check is a keyless integer test over 64 elements, so it runs before any asymmetric work.
| Path | Cost per request | Junk rejected / second |
|---|---|---|
| Reject at ℤ6 admission filter | 0.36 µs | 2,777,778 |
| Reject after ML-KEM decapsulation | 585.39 µs | 1,708 |
| Advantage | 1,626.1× cheaper — 99.94% of CPU avoided per junk request | |
Unstructured key material is admitted at a rate of 1 in 1296. In fairness, any inexpensive pre-filter yields this shape of saving — a keyed MAC would too. What ℤ6 contributes specifically is that the check is structural and keyless: no shared secret, no server-side state, which is what makes it usable on an anonymous stateless endpoint where a MAC is not available.
| Operation | Median | Role |
|---|---|---|
| ℤ6 moat validation (64 elements) | 0.36 µs | admission screening |
| ℤ6 moat-valid key generation | 5.34 µs | client key construction |
| ℤ6 pack / unpack (24 B) | 0.42 µs | wire encoding |
| ML-KEM-768 encapsulate (JS runtime) | 534.25 µs | client key agreement |
| ML-KEM-768 decapsulate (JS runtime) | 585.39 µs | server key agreement |
| HKDF-SHA256 derive | 34.87 µs | key derivation |
| X25519 keygen / ECDH | 34.21 / 33.89 µs | classical baseline |
The JavaScript ML-KEM used in the Worker runtime is roughly 8× slower than the PQClean C reference (57.4 / 63.1 / 77.9 µs). Both are reported.
| Configuration | Bytes on wire | Within 1500 B MTU |
|---|---|---|
| X25519 (classical, pre-quantum) | 64 | Yes |
| ML-KEM-768 full handshake | 2,272 | No |
| ML-KEM-1024 full handshake | 3,136 | No |
| HQC-128 | 6,682 | No |
| Classic McEliece-348864 | 261,216 | No |
| Z6P v4 sealed message (server key cached) | 1,188 | Yes |
Because the 1,184-byte server public key is fetched once and cached, only the ML-KEM ciphertext travels per message. That keeps a sealed message inside a single MTU where a full ML-KEM-768 handshake would fragment.
| Concurrency | Throughput | p50 | p95 | Success |
|---|---|---|---|---|
| sequential | — | 33 ms | 57 ms | 30/30 |
| 10 | 90 req/s | 64 ms | 329 ms | 60/60 |
| 25 | 236 req/s | 84 ms | 225 ms | 150/150 |
| 50 | 278 req/s | 163 ms | 270 ms | 300/300 |
510 of 510 concurrent requests completed with no failures. Throughput is bounded by the measuring client and its network path, not by a datacentre capacity ceiling.
| Property | v3 | v4 (live) |
|---|---|---|
| Shared secret derivable from transcript | Yes — demonstrated | No |
| Key establishment | custom; public key equalled private key | ML-KEM-768 (FIPS 203) |
| Admission filter | advisory headers only | enforced, HTTP 403 |
| Admission-valid key space | 216 keys (7.75 bits) | ~660 (155.1 bits) |
| Context binding | No | Yes — verified |
| Median latency | 36 ms | 33 ms |
Both paths are live on this host and were timed under identical conditions. The legacy route is marginally faster because it performs no real key establishment; its transcript remains derivable offline, which is why it is deprecated rather than recommended. The 3 ms difference is the entire latency cost of adding genuine post-quantum key establishment to this service.
Every KEM below was benchmarked on the same machine with the same method, using the reference C implementations (PQClean) of the NIST standard and alternate schemes. Nobody builds exactly this, so the comparison is against what the industry actually deploys for post-quantum key agreement.
| Scheme | Status | Public key | Transit | Keygen | Encaps | Decaps | Fits MTU |
|---|---|---|---|---|---|---|---|
| X25519 (classical baseline) | RFC 7748 | 32 B | 64 B | 31.1 µs | 32.9 µs | 32.9 µs | Yes |
| ML-KEM-512 | NIST FIPS 203 | 800 B | 1,568 B | 34.7 µs | 39.9 µs | 50.5 µs | No |
| ML-KEM-768 (the deployed choice) | NIST FIPS 203 | 1,184 B | 2,272 B | 57.4 µs | 63.1 µs | 77.9 µs | No |
| ML-KEM-1024 | NIST FIPS 203 | 1,568 B | 3,136 B | 87.2 µs | 93.3 µs | 114.1 µs | No |
| HQC-128 | NIST alternate | 2,249 B | 6,682 B | 1,437 µs | 2,931 µs | 4,778 µs | No |
| Classic McEliece-348864 | NIST alternate | 261,120 B | 261,216 B | 83,947 µs | 105 µs | 18,881 µs | No |
| Z6 lattice KEM | Research — unvetted | 24 B | 160 B | 10.2 µs | 18.3 µs | 7.3 µs | Yes |
Z6 is the smallest and fastest row in the table. That result is real and reproducible — and on its own it does not make Z6 a better choice than ML-KEM. Three reasons:
| Axis | ML-KEM-768 | Z6 lattice KEM |
|---|---|---|
| Security analysis | Multi-year NIST process, public cryptanalysis, security proofs | None. No external review, no proof, no published attack surface |
| Stated security level | NIST Category 3 | 165-bit key space — a keyspace size, not an assessed security level |
| Interoperability | X25519MLKEM768: one hybrid the whole industry converged on | Proprietary. Interoperates with nothing |
| Regulatory standing | FIPS-validated path for the 2030 federal deadlines | Not FIPS, not eligible |
| Deployment | Majority of browser traffic to major CDNs | This gateway |
Why smaller and faster is not automatically better. ML-KEM's 1,184-byte key and its keygen cost buy something specific: module-lattice operations whose hardness has been studied publicly for years. Z6 keygen samples 64 elements and bit-packs them, so it is cheap precisely because it does less mathematical work. A fair reading is that Z6 occupies a different point on the curve — extremely compact and MTU-resident, with an unquantified security margin — not that it dominates ML-KEM.
The interoperability lesson. The TLS ecosystem converged on a single hybrid (X25519MLKEM768) and deployment followed quickly; by mid-2026 post-quantum key agreement covers the majority of browser traffic to Cloudflare, and Executive Order 14412 set federal deadlines of 2030 for post-quantum encryption. IPsec went the other way — vendors shipped proprietary post-quantum key agreements that could not interoperate, and the migration was delayed by years. Z6 is, by construction, in that second category. It is a research protocol exploring what a compact ℤ₆ construction can do, not a drop-in replacement for a standardised KEM.
Method: PQClean reference implementations via pqcrypto, median of 3–300
iterations per operation depending on scheme cost, single machine, same process. Z6 timings are
a local reimplementation of the deployed construction (sample → pack, HKDF-SHA256,
AES-256-GCM); Z6 transit is measured from a live gateway envelope. Sizes for the NIST schemes
are the implementations' own, matching the published parameters. Harness is reproducible.