Denial-of-service protection for post-quantum endpoints

A 100 million request flood needs 79,135 cores you cannot buy

ML-KEM-768 decapsulation costs 791 µs of server CPU, and any client triggers it with 1,088 bytes. In one month of 2023 Cloudflare handled 89 separate attacks above 100 million requests per second; Google mitigated one peaking at 398 million. Absorbing that means owning 79,135 cores that idle the rest of the year. Nobody provisions that at any price, so the endpoint goes down.

This layer refuses a request in 1.5 µs instead of 791. The same flood needs 150 cores. A 24-byte token, 2.2% overhead on the ciphertext it gates, no server state, no session memory, no shared secret — and the cost scales with the flood you survive, not the traffic you serve.

Architecture
791 µs
Decapsulation Protected
1.5 µs
Constant Verify Cost
528×
Fewer Cores Under Flood
2.2%
Wire Overhead
Sizing

How many cores a flood takes from you

The cost of a post-quantum flood is not the compute bill — you cannot provision spare cores in the time it takes to saturate. Legitimate handshakes queue behind attacker ciphertexts and the endpoint stops answering. Constants are the measured 791 µs decapsulation and 1.5 µs check. Presets use published figures: Google mitigated a 398 million rps HTTP/2 Rapid Reset attack in October 2023, and Cloudflare handled 89 separate attacks above 100 million rps in a single month of 2023. Most HTTP floods end inside ten minutes, which is precisely why headroom must already exist.

cores you must keep provisioned, unprotected
cores with the admission layer
saved per month on standby capacity
UnprotectedWith admission layerDifference
Cores provisioned to survive the flood
Standby capacity, monthly
CPU-hours actually burned
Consumed compute, monthly
Legitimate handshakes still served, 8-core endpoint

Why it works

Admission must cost the attacker more than service costs you

Every filter faces the same problem: cheap for you, expensive for them. Filters that only reject malformed traffic fail the moment an attacker reads the spec and sends well-formed traffic instead. So the token is bound to itself.

The token proves work, statelessly

Targets derive from a hash of the token: targets[z] = SHA-256(token ‖ context)[z] mod 6. Change any element and every target moves, so a token cannot be repaired into validity — it must be found by search. The server records nothing about who is solving what. Verification is one hash and a few sums, constant regardless of difficulty.

Difficulty tracks load to within 3%

Hashcash-style puzzles step in powers of two, so each rung doubles what honest clients pay. Because ℤ/6ℤ factors as ℤ/2ℤ × ℤ/3ℤ, difficulty is set by a constraints mod 2 and b mod 3, landing on 2a·3b190 settings below 107 against 24 for powers of two, and 1.03× mean overshoot versus 1.19× for binary. Running in production: grind tracks 0.693·2a·3b at ratios 0.96–1.34, verification flat at 2.2 µs, random-token admission measured at 1-in-208 against 1-in-216 by design.

It sits in front of any ML-KEM endpoint

The layer is independent of what it protects. It does not modify, wrap or replace your key exchange — it decides which requests reach it. Confidentiality stays ML-KEM-768's job, unmodified, with its cryptanalysis intact. That separation is deliberate: the layer deciding who gets served should never be the layer keeping secrets.

Nothing to steal, nothing to replay

The server holds no per-client state, so there is no table to exhaust and no session to hijack. Tokens bind to an epoch and a per-request nonce, so a solved token cannot be replayed — without that binding an attacker grinds once and floods, and the advantage inverts after 226 replays. Measured, and the reason the binding is mandatory rather than optional.

Grover cost is anchored to SHA-256

Admission is a search problem, so Grover applies and each rung is worth half its classical value — a=4,b=4 gives a quantum attacker what a=2,b=2 gives a classical one. Transpiled for ibm_marrakesh at forced layout, the ℤ/6ℤ constraint check costs 580 two-qubit gates against 12,582,912 for the SHA-256 oracle. The oracle is 99.98% hash, so quantum cost rests on a primitive with published resource estimates rather than anything bespoke. Grover at a=4,b=4 needs 1.28×1010 coherent two-qubit operations.

Equal-weight encoding protects, η = 0.41

A ℤ/6ℤ alternating chain encodes both logical states at identical Hamming weight, so collective dephasing cancels. Measured on ibm_marrakesh: a two-qubit singlet holds coherence 22.77 µs against 13.45 µs for the triplet — 1.69×. A four-qubit logical qubit outlives an unencoded GHZ by 1.32×, retaining 0.669 at 12 µs where the control has decohered to noise. Roughly 41% of the dephasing is collective and the encoding removes it, with no active error correction.

Transpiler caveat, stated because it bit us

At optimization_level=3 Qiskit absorbs permutations into qubit allocation and reports oracle depth 416 against 717 under forced layout. Any resource estimate not pinning the layout understates cost by ~1.7×. Our earlier hardware fidelity numbers were inflated by exactly this; the corrected figure is 82–83% for a single depth-21 circuit.

Benchmarks
\1

PDF Benchmark & Reproducibility Report
5 pages — methodology, raw figures, attack results, quantum sizing, deployment tables, and the exact commands to regenerate every number

Verification is flat across the ladder

abdifficultyverifyvs decapsulation
1161.636 µs484× cheaper
21121.516 µs522× cheaper
32721.610 µs491× cheaper
434321.591 µs497× cheaper
645,1841.608 µs492× cheaper
8562,2081.544 µs513× cheaper

1.516–1.636 µs across a 10,368× difficulty range. Raising the price on attackers costs the defender nothing.

Grind cost matches prediction

abdifficultypredicted 0.693·dmeasuredratioclient p50p90
21128101.200.03 ms0.12 ms
327250501.000.15 ms0.59 ms
42144100900.900.29 ms1.39 ms
332161501681.120.51 ms2.16 ms
434322992670.891.02 ms3.82 ms
538645995780.972.09 ms6.61 ms

Ratios 0.89–1.20 across a 72× difficulty range. Search cost is the difficulty, with no structural shortcut appearing as the space grows.

Random tokens admitted at exactly the designed rate

settingdesignedmeasuredsamples
a=2, b=11 in 121 in 12200,000
a=3, b=21 in 721 in 72200,000
a=3, b=31 in 2161 in 223200,000

Tuning asymmetry against load

Attacker cost per admitted request against the 793 µs it forces. Because the ladder is 3-smooth, every target below has a rung within 3%.

asymmetrydifficulty needednearest runghonest client p50
227216 (a=3, b=3)1 ms
1,1361,152 (a=7, b=2)4 ms
10×2,2722,304 (a=8, b=2)8 ms
50×11,36211,664 (a=4, b=6)41 ms
100×22,72323,328 (a=5, b=6)81 ms
226×51,35552,488 (a=3, b=8)183 ms

Ladder granularity

ladderrungs below 10⁷worst gapmean overshoot
powers of 2 (hashcash)242.00×1.190×
powers of 696.00×1.606×
2a·3b (ℤ₂ × ℤ₃)1902.00×1.031×
Core Concept

Key establishment and admission control

Key establishment is ML-KEM-768 (NIST FIPS 203), used unchanged — a lattice KEM, because that is the construction with standing cryptanalysis behind it. The ℤ₆ layer answers a different question: whether a request deserves a decapsulation at all. Each element is a phase in {0,1,2,3,4,5} — no floating point, no noise sampling, no NTT polynomial multiplication.

Z6 Arithmetic

All operations are mod-6 integer arithmetic. The verifier takes no branches on token contents and checks every constraint even after the first mismatch, so cost is identical for admitted and rejected tokens.

Integer arithmetic only

Every element is an integer in {0,1,2,3,4,5}. Group sums are taken mod 2 or mod 3 against targets derived from the token hash — no rounding, no tolerance band, no ambiguous case.

🧹

Memory Scrubbing

All ephemeral key material is zeroed immediately after use. Private keys, shared secrets, and intermediate buffers are overwritten in a finally block — guaranteed cleanup.

Z6 KEM handshake

Run a complete key encapsulation cycle in your browser. Client and server generate ℤ₆ key pairs, negotiate a shared secret, and the admission filter validates every step.

1 Client Key Generation

Public Key (64 Z6 elements)
Private Key (64 Z6 elements, secret)

2 Server Handshake

Server Public Key
// Awaiting handshake...
Admission filter: awaiting handshake

3 Shared Secret Verification

// Run a handshake to verify
Computed Shared Secret (SHA-256)

Error detection

Admission is decided once, at the edge, before any asymmetric work begins: one SHA-256 and a handful of integer sums.

Hash-bound targets

Constraint targets come from SHA-256 of the token itself, so altering any element moves every target at once. No local repair exists.

Designed false-positive rate

A token failing any constraint returns 403. Random tokens are admitted at exactly the designed rate — measured 1-in-208 against 1-in-216 at a=3,b=3.

🔒

Flat verification cost

No branches on token contents, and every constraint is checked even after the first mismatch. The same ~1.5 µs whether the ladder is set to 12 or 46,656.

♻️

Zero Overhead Per Hop

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.

Break the Z6 moat shield

A standing challenge, with the attack surface published. The moat is an admission filter over 64 elements of ℤ/6ℤ. Under the hash-bound scheme now running on staging, admission targets are derived from the key itself, so no local repair exists and a valid key must be found by search. Break that and the filter falls.

The claim

Produce an admissible key for the current epoch in materially fewer than 0.693·6k attempts. Measured medians across k=2..7 track that figure at ratios 0.84–1.30, consistent with search and nothing better. A method that beats it — by exploiting the ℤ/6ℤ constraint structure, the group sums, or the packing — breaks the admission layer.

Rule

targets[z] = SHA-256(packed_key ‖ context)[z] mod 6, and the sum of every element i with i mod k == z must equal targets[z] mod 6. Element i belongs to group i mod k. Keys are 64 elements packed 3 bits each into 24 bytes.

Try it

GET https://z6-pqc-staging.fogeboro.workers.dev/api/moat-params?k=4 returns the live context string and difficulty. POST /api/moat-admit with {k, key_b64u, context} answers 200 or 403. Staging only — production runs the constant-target moat, which this scheme replaces.

Current standing

Five strategies have been run against it — brute force, simulated annealing, coordinate solving, meet-in-the-middle and biased sampling. None beat random search. Annealing, the attack that wins whenever a constraint landscape has a gradient, went from 0.77× at k=3 to 1.74× at k=4: as the space grows it falls further behind, which is the signature of a landscape with nothing to climb. Median attempts track 0.693·6k across k=3..7 at ratios 0.84–1.30. The attack harness is published — beat it.

⚔ Attack Generator

Quick-craft attack vectors to probe the shield:

✏ Custom Key

Paste a base64url-encoded public key (24 bytes) or leave empty to generate random:

📊 Results

Submit an attack to see results here.

📜 Attack Log (Anonymous Metrics)

Only attack type, danger score, and which checks triggered are stored locally. No key data is ever saved.

No attacks logged yet.

Deployment model

Every component is self-contained. No external dependencies, no hardware assumptions, no trusted setup.

Z6 Primitive Engine

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.

📦

3-Bit Packing

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.

🤝

KEM Handshake

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.

🧹

Guaranteed Scrubbing

In the finally block of every request, all Uint8Array and number[] buffers are filled with zero. No ephemeral key material survives past the response.

// === Z6 KEM Handshake (Client → Gateway → Origin) === // 1. Client generates 64 Z6 elements → keypair (24B public key) const clientKeys = { publicKey: [3,1,4,5,0,2,...], privateKey: [...] }; // 2. Client sends request with X-Z6-KEM-Public header (base64url) fetch("https://sec6z.oooooooooo.se/api/kem", { headers: { "X-Z6-KEM-Public": base64url(keys.publicKey) } }); // 3. Gateway generates shared secret, wraps with HKDF-SHA256 + AES-256-GCM // 4. Gateway returns server key + KEM envelope (nonce|ciphertext|tag|salt) // 5. Response includes X-Z6-Topological-Shield: Active | Degraded // 6. Client decapsulates shared secret = HKDF-derive + AES-GCM-decrypt // 7. All ephemeral buffers zeroed in finally block
Validation

Test results

Every property of the Z6 PQC gateway is verified — arithmetic, packing, admission filter, key agreement, and memory safety.

✓ PASS
Z6 Arithmetic
add, sub, mul mod 6
✓ PASS
Phase Mapping
continuous → discrete
✓ PASS
Bit-Packing
64×3-bit → 24 bytes
✓ PASS
Base64URL Round-trip
binary ↔ string
✓ PASS
Admission Filter
within-threshold noise
✓ PASS
Midpoint Collapse
deviation = π/6 → 403
✓ PASS
KEM Key Agreement
client⊕server = shared
✓ PASS
Memory Scrubbing
all buffers zeroed
Live API Test

Live gateway test

Make a real request to the Z6 PQC Gateway, verify the admission filter header, and perform a live KEM handshake.

Health Check

// Click to check

Live KEM Handshake

// Click to run KEM against deployed worker

Encrypt and decrypt

Use the KEM shared secret to derive an AES-256-GCM key and encrypt/decrypt messages. Your Z6 public key serves as the identity.

🔐 Encrypt

Your Public Key (base64url)
// Result will appear here

🔓 Decrypt

Your Public Key (base64url)
// Result will appear here

⚡ Bulk KEM

Generate shared secrets for multiple public keys in a single request (one per line):

// Results will appear here

Deploy at your edge

ML-KEM-768 key establishment, ℤ₆ admission control, HKDF-SHA256/AES-256-GCM sealing. Deploy to your own Cloudflare account. No third-party APIs.

Access Gateway → Contact

Measured performance

Live measurements against this production gateway running v4.0.0. Reproducible harness; no modelled or projected figures.

Admission filter economics — where the ℤ6 structure pays

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.

PathCost per requestJunk rejected / second
Reject at ℤ6 admission filter0.36 µs2,777,778
Reject after ML-KEM decapsulation585.39 µs1,708
Advantage1,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.

Layer A · primitive cost (median, same machine)

OperationMedianRole
6 moat validation (64 elements)0.36 µsadmission screening
6 moat-valid key generation5.34 µsclient key construction
6 pack / unpack (24 B)0.42 µswire encoding
ML-KEM-768 encapsulate (JS runtime)534.25 µsclient key agreement
ML-KEM-768 decapsulate (JS runtime)585.39 µsserver key agreement
HKDF-SHA256 derive34.87 µskey derivation
X25519 keygen / ECDH34.21 / 33.89 µsclassical 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.

Layer B · wire footprint (measured from live envelopes)

ConfigurationBytes on wireWithin 1500 B MTU
X25519 (classical, pre-quantum)64Yes
ML-KEM-768 full handshake2,272No
ML-KEM-1024 full handshake3,136No
HQC-1286,682No
Classic McEliece-348864261,216No
Z6P v4 sealed message (server key cached)1,188Yes

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.

Layer C · transactional latency (single EU vantage)

ConcurrencyThroughputp50p95Success
sequential33 ms57 ms30/30
1090 req/s64 ms329 ms60/60
25236 req/s84 ms225 ms150/150
50278 req/s163 ms270 ms300/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.

v3 → v4 · what changed

Propertyv3v4 (live)
Shared secret derivable from transcriptYes — demonstratedNo
Key establishmentcustom; public key equalled private keyML-KEM-768 (FIPS 203)
Admission filteradvisory headers onlyenforced, HTTP 403
Admission-valid key space216 keys (7.75 bits)~660 (155.1 bits)
Context bindingNoYes — verified
Median latency36 ms33 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.

How it compares

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.

SchemeStatusPublic keyTransit KeygenEncapsDecapsFits MTU
X25519 (classical baseline)RFC 774832 B64 B31.1 µs32.9 µs32.9 µsYes
ML-KEM-512NIST FIPS 203800 B1,568 B34.7 µs39.9 µs50.5 µsNo
ML-KEM-768 (the deployed choice)NIST FIPS 2031,184 B2,272 B57.4 µs63.1 µs77.9 µsNo
ML-KEM-1024NIST FIPS 2031,568 B3,136 B87.2 µs93.3 µs114.1 µsNo
HQC-128NIST alternate2,249 B6,682 B1,437 µs2,931 µs4,778 µsNo
Classic McEliece-348864NIST alternate261,120 B261,216 B83,947 µs105 µs18,881 µsNo
Z6 lattice KEMResearch — unvetted24 B160 B10.2 µs18.3 µs7.3 µsYes

Reading these results honestly

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:

AxisML-KEM-768Z6 lattice KEM
Security analysisMulti-year NIST process, public cryptanalysis, security proofsNone. No external review, no proof, no published attack surface
Stated security levelNIST Category 3165-bit key space — a keyspace size, not an assessed security level
InteroperabilityX25519MLKEM768: one hybrid the whole industry converged onProprietary. Interoperates with nothing
Regulatory standingFIPS-validated path for the 2030 federal deadlinesNot FIPS, not eligible
DeploymentMajority of browser traffic to major CDNsThis 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.