Post-Quantum Web Cryptography:
The SIMD Performance Cliff

A statistical evaluation of FIPS 203 ML-KEM-768 hybrid key exchange across 462 browser sessions (67% lab-controlled). WASM achieves 3.45× observed latency reduction over pure JS (2.34 ms vs 8.07 ms), though 87% of total handshake latency is uninstrumented framework overhead—cryptographic core operations show 7–9× speedup.

3.45×
WASM vs JS Observed Ratio
462
Evaluated Sessions
2.34ms
WASM Mean Latency
v2.0.0 · FIPS 203 ML-KEM-768 · X25519 Hybrid · WASM + JS
DOI 10.5281/zenodo.20106243

WASM vs JavaScript Performance

WebAssembly delivers a 3.45× observed latency reduction over pure JavaScript for ML-KEM-768 operations (2.34 ms vs 8.07 ms; p < 0.0001, survives Bonferroni correction). However, 87% of total handshake latency is uninstrumented framework overhead—the cryptographic core advantage is 7–9×. Browser-vintage stratification reveals a coherent latency ordering across five strata, and SIMD-based comparisons are disabled due to unreliable WebAssembly.validate() feature detection.

Mean Handshake Latency (ms)

WASM: Sub-5ms Execution

WebAssembly executes the FIPS 203 ML-KEM-768 hybrid handshake in a mean of 2.34 ms (median 1.28 ms), with modern Chromium-based engines averaging 1.82 ms. Caveat: Only 13% of this latency is measured cryptographic core; 87% is uninstrumented framework overhead.

Legacy Browser & SIMD Detection

One Chrome 87 session on macOS 10.10.5 (WASM: 395.7 ms, n=1) is formally excluded as an outlier. Seven Safari sessions reporting simd=false achieved sub-millisecond latencies, proving WebAssembly.validate() is unreliable for SIMD stratification.

Browser-Vintage & Global South

Browser-vintage stratification yields a coherent latency ordering: Safari 0.67 ms < Modern Chromium 1.68 ms < Mature Chromium 2.87 ms < Firefox 6.92 ms. Field data from South Asia (n=155) confirms budget SoC tiers support modern WASM runtimes—though this is a Bangladesh-case study, not globally representative.

Test Your Environment

Run the verified cryptographic implementations directly in your active browser context.

WebAssembly

Binary execution compiled from C via Emscripten. Delivers consistent performance across modern browsers with WASM runtime support.

Mean 2.34 ms
KeyGen 0.16 ms
Encaps 0.18 ms
Execute WASM Probe

Pure JavaScript

Universal fallback using ECMAScript standards without compilation dependencies. Demonstrates interpreted engine efficiency.

Mean 8.07 ms
KeyGen 1.18 ms
Encaps 1.42 ms
Execute JS Probe

Research Methodology

Our framework resolves critical web-cryptography evaluation pitfalls by applying strict control heuristics inside the browser engine.

Strict FIPS 203 Compliance

Integrates NIST-mandated hash domain separations (0x06, 0x1F) and the critical dimension parameter ($k$) concatenation, resolving common vulnerabilities in pre-standard "Kyber Round 3" ports.

JIT Warm-up Isolation

We enforce a time-based 200 ms warm-up phase (empirically validated: CV stabilizes below 5% after 150–180 ms across all engines) before collecting N=50 timed iterations. Sessions where the first timed iteration exceeded 150% of session median are flagged and excluded (n=3, 0.6%).

Memory Zeroization Protocol

C volatile memset wrappers paired with JS Uint8Array.fill(0) zeroing. Warning: Zeroization is not guaranteed—JIT optimization, engine-internal buffer copies, and WASM linear memory visibility to same-origin JS can defeat it. Unsuitable for long-lived secrets.

Constant-Time Screening Harness

Incorporates a developmental Welch's t-test heuristic to screen Fujisaki-Okamoto (FO) transform rejections ($|t| < 2.0$ observed). Note: Production requires formal TVLA validation.