Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

arXiv:2611.01989v1 [cs.CR] 1 Nov 2026

A Preprint

Sota Yamawaki Graduate School of Informatics Kyoto University Yoshida-honmachi, Sakyo-ku, Kyoto 606-8501, Japan yamawaki.souta.36p@st.kyoto-u.ac.jp

Yasuo Okabe Academic Center for Computing and Media Studies Kyoto University Yoshida-honmachi, Sakyo-ku, Kyoto 606-8501, Japan okabe@i.kyoto-u.ac.jp

Abstract WebAssembly (Wasm) runs untrusted code in a portable, lightweight sandbox and is increasingly used to host services on shared servers and edge platforms. Running the QUIC transport protocol inside Wasm would let each application choose and update its own transport without changing the host. QUIC, however, encrypts every packet, and Wasm offers neither dedicated AES instructions nor carry-less multiplication; a Wasm QUIC stack has been reported to reach only 17.6% of native goodput, with cryptography as its largest cost. Whether the 128-bit SIMD extension of Wasm (WASM-SIMD) can recover this cost, and what limits a pure-Wasm stack once it does, has remained unclear. Here we show that explicit WASM-SIMD kernels recover much of the cryptographic cost, after which non-cryptographic costs become the limit. On two hosts connected by 10-Gigabit Ethernet, kernels that process eight AES blocks or four ChaCha20 blocks per pass raise receiver goodput over a non-SIMD baseline by 61.34% for AES-128-GCM and 31.55% for ChaCha20-Poly1305, whereas compiler auto-vectorization gains only 1.28% for AES-128-GCM. ChaCha20-Poly1305 still delivers 1.99 times the goodput of AES-128-GCM, confirming end to end the preference that stand-alone cipher benchmarks suggest. Receiver-side profiling combined with Amdahl’s law predicts that even native-speed cryptography would leave Wasm at roughly one third of the goodput of the fastest native stack. Cryptographic acceleration is therefore necessary but not sufficient: memory allocation, runtime overhead and per-datagram UDP I/O now bound pure-Wasm transports. We anticipate that this per-category cost breakdown will guide further optimization of Wasm network stacks and the design of system interfaces for batched I/O. Keywords WebAssembly · QUIC · WASM-SIMD · Authenticated encryption

1

Introduction

Running the entire QUIC transport [3, 4] inside WebAssembly (Wasm) lets each application on a shared server or edge platform replace and update its transport without modifying the host [5]. Wasm and the WebAssembly System Interface (WASI) offer such platforms language independence and lightweight sandboxing [1], and recent work composes QUIC stacks from isolated Wasm components [2]. This flexibility costs performance, mainly in cryptography, because Wasm lacks the instructions that make encryption cheap on native platforms. QUIC applies authenticated encryption to every packet. On native platforms, dedicated AES instructions keep this cost small: disabling packet protection improves performance by only 10–20% [6], and the throughput gap between QUIC and TCP on fast links stems mainly from packet processing rather than encryption [14]. Wasm, in contrast, prioritizes portability and lacks both dedicated AES and carry-less multiplication instructions [9]. Spies et al. [2] found that their fastest Wasm configuration reached only 17.6% of the goodput of the fastest native configuration, with cryptography as the largest contributor to the gap. A Japanese version of this work has been submitted as a manuscript for presentation at the IEICE Technical Committee on Internet Architecture (IA). The abstract is available at https://ken.ieice.org/ken/paper/202611028cZo/eng/.

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

Without AES instructions, the usual preference for AES-GCM also becomes questionable. TLS 1.3 requires AES-128GCM and recommends AES-256-GCM and ChaCha20-Poly1305 among its authenticated encryption with associated data (AEAD) algorithms [25], and QUIC uses the same cipher suites [7]. Which of AES-128-GCM and ChaCha20Poly1305 is faster depends on whether the platform provides AES instructions [8], so the native ranking cannot be assumed in Wasm. Delegating cryptography to the host would sidestep the problem but undermine the reason for a Wasm transport. A host interface such as WASI-Crypto [18], or TLS termination by the host, ties the transport to features that every platform must provide, moves key material across the sandbox boundary, and, for QUIC, requires a guest–host call per packet. A pure-Wasm stack avoids these dependencies but must make cryptography fast with the instructions that Wasm offers. Existing work leaves two questions open: whether WASM-SIMD, the 128-bit single-instruction-multiple-data extension of Wasm, can recover a substantial part of the cryptographic cost, and what limits a pure-Wasm QUIC stack once it does. The first is unsettled because the Wasm build of BoringSSL used by Spies et al. was a generic implementation with assembly disabled, and stand-alone benchmarks of Wasm ciphers [19] do not show how cipher speed translates into the goodput and CPU time of a complete QUIC transfer. The second requires attributing CPU time to processing categories, not only measuring throughput. We answer both questions with explicit WASM-SIMD kernels in a pure-Wasm QUIC stack that targets WASI 0.3, evaluated on two hosts connected by 10-Gigabit Ethernet (10GbE). The underlying techniques, bitsliced [15] and fixsliced [17] AES and vectorized ChaCha20 [16], are known; we adapt them to WASM-SIMD and quantify their end-to-end effect on QUIC. Our contributions are threefold: 1. Cryptographic kernels tailored to WASM-SIMD. An eight-block fixsliced AES kernel and a four-block ChaCha20 kernel with shuffle-based rotations raise goodput over the non-SIMD baseline by 61.34% with AES-128-GCM and 31.55% with ChaCha20-Poly1305. Auto-vectorization alone gains only 1.28% with AES-128-GCM. 2. An end-to-end comparison of ciphers in pure Wasm. ChaCha20-Poly1305 delivers 2.44 times the goodput of AES-128-GCM without SIMD and 1.99 times with our kernels. This turns the preference suggested by stand-alone benchmarks [19] into an end-to-end measurement. 3. A quantification of the costs that remain. A per-category breakdown of receiver CPU time and Amdahl’s law show that even native-level cryptography would leave Wasm at about one third of the fastest native goodput. Memory allocation, runtime overhead, and per-datagram socket I/O emerge as the next targets. Scope. We study the receiving side of a bulk transfer over a single, lossless QUIC connection between two x86-64 hosts, with Wasmtime as the runtime and AES-128-GCM and ChaCha20-Poly1305 as the AEADs. We do not evaluate Wasm senders, AES-256-GCM, short connections, lossy or high-latency paths, or other runtimes and instruction sets; Section 9 discusses what our conclusions do and do not cover. Sections 2 and 3 give background and related work. Sections 4 and 5 describe our stack, the evaluated configurations, and the methodology. Section 6 profiles the baseline, Section 7 presents the kernels, and Section 8 evaluates them. Section 9 discusses limitations, and Section 10 concludes.

2

Background

2.1

WebAssembly and WASI

Wasm [10] is a sandboxed, stack-based instruction set, and WASI [11] exposes host functionality to it outside the browser. A Wasm module runs isolated from the host in its own linear memory and interacts with the host only through explicit imports and exports. WASI defines host functionality, such as sockets and clocks, as type-safe interfaces via the Component Model and WebAssembly Interface Types (WIT). WASI 0.3 (formerly Preview 3) [28], which this paper targets, adds asynchronous functions to the Component Model and makes socket send and receive asynchronous; the guest waits for outstanding operations by grouping them in a waitable set. Wasm adds costs that native code does not pay, both at the host boundary and in computation. Every host-function call passes through the runtime, and a received packet may be copied from host-side buffers into linear memory in addition to the copy from the OS kernel to user space. Even compute-bound code runs slower: with default bounds checking, performance-oriented runtimes execute PolyBench/C kernels within 20% of native execution time on x86-64 and within 35% on Armv8 [12]. A comparison between Wasm and native execution must therefore account for memory operations and host calls as well as computation.

2

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

2.2

A Preprint

QUIC and Authenticated Encryption

QUIC [3] runs over the UDP and protects every packet with authenticated encryption keyed by the TLS 1.3 key schedule [7]. A separate header protection additionally masks part of the header, including the packet number. Initial packets are always protected with AES-128-GCM [7]. The two AEADs we compare use different ciphers but structurally similar MACs. AES-128-GCM [38] combines AES-128 in counter (CTR) mode with GHASH, a universal hash over GF(2128 ). Each AES round applies byte substitution through S-boxes (SubBytes), a byte permutation (ShiftRows), a matrix multiplication over a finite field (MixColumns), and a key addition. ChaCha20-Poly1305 [37] combines the ChaCha20 stream cipher, which uses only 32-bit additions, rotations, and XORs (ARX), with the Poly1305 message authentication code (MAC). Both MACs evaluate a polynomial, over GF(2128 ) for GHASH and modulo the prime 2130 − 5 for Poly1305. 2.3

SIMD and WASM-SIMD

SIMD accelerates computations that apply the same operation to independent data. It splits a vector register into lanes and applies one instruction to all of them. Computations that depend on the immediately preceding result, carry across lanes, branch on data, or access memory non-contiguously are hard to vectorize. Cryptographic code can exploit SIMD across blocks or across bits, through either the compiler or hand-written kernels. Compiler auto-vectorization needs no code changes, whereas explicit kernels design the data layout and operation sequence for the vector unit. Kernels either process multiple blocks under the same key in parallel or distribute a bit-level state across lanes. The latter, bitslicing, gathers the 𝑖-th bits of many blocks in one word so that the S-box can be evaluated with logic operations instead of table lookups. WASM-SIMD [9] is narrower and less complete than native SIMD extensions, and these gaps shape our kernels in Section 7. Its vector width is fixed at 128 bits, compared with 256 and 512 bits for AVX2 and AVX-512. It offers no AES instructions, no carry-less multiplication, and no lane-wise rotate. Byte permutations are available as i8x16.shuffle, whose mask is a compile-time constant, and i8x16.swizzle, whose mask is a run-time value.

3

Related Work

QUIC and network stacks in Wasm. Prior work on Wasm network stacks has identified cryptography and I/O as bottlenecks but has not accelerated cryptography with WASM-SIMD. WATER [5] distributes censorship-circumvention transports as Wasm modules that can be updated without modifying the application; its appendix notes that cryptography in Wasm is slower than native for lack of hardware acceleration. Spies et al. [2] composed a QUIC stack from Wasm components and evaluated an HTTP/3 server based on quiche and BoringSSL over the loopback path of a single machine. Their CPU-cycle breakdown identified cryptography, memory copies, and socket I/O through WASI as the main bottlenecks, but their Wasm BoringSSL was a generic build with assembly disabled. Aoyagi and Okabe [13] batched multiple datagrams into a single list per UDP send and receive call within standard WASI Preview 2, raising the goodput of a quiche-based HTTP/3 server on 10GbE from 13.2% to 15.5% of native; our work on cryptography is complementary. The polymorph-tls project [36] provides a pure-Wasm TLS 1.3 implementation with a QUIC compatibility layer and reports that fixsliced AES-128-GCM with software GHASH is much slower than ChaCha20-Poly1305 at QUIC packet sizes. We found neither SIMD kernels nor an end-to-end receiver CPU profile in that project. QUIC performance and the cost of cryptography. On native platforms, where hardware AES is available, cryptography is a secondary cost of QUIC. QUIC runs congestion control, retransmission, and other tasks in user space, so CPU processing can limit throughput on fast links [4]. Zhang et al. [14] showed that QUIC can be up to 45.2% slower than TCP+TLS+HTTP/2 on fast links and attributed this to receiver-side packet processing rather than encryption. König et al. [34] found that QUIC implementations still fall short of TCP on 10GbE, often because of per-packet processing. Kempf et al. [6] measured a 10–20% gain from disabling packet protection and found AES-based header protection inexpensive. Jaeger et al. [8] showed that packet I/O becomes the main load in native QUIC with AES-NI or ChaCha20. In the versions of LSQUIC and quiche they evaluated (January 2023), enabling Generic Segmentation Offload (GSO) and its receive counterpart did not improve goodput, and application-side support for batched I/O was limited; enabling offloads alone thus did not remove the packet I/O bottleneck. Mukherjee et al. [33] observed that the choice of cryptographic library substantially affects QUIC throughput, and Oku [35] showed that libraries not optimized for packet-sized inputs inflate the AEAD cost of QUIC. Without hardware AES, Wasm shifts this balance, and this is the regime we study.

3

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

Cryptography in Wasm. Prior work on cryptography in Wasm has addressed verification, constant-time guarantees, host delegation, and stand-alone speed, but not end-to-end transport performance. Protzenko et al. [31] compiled the verified HACL∗ library to Wasm before WASM-SIMD was standardized. CT-Wasm [32] and the constant-time WebAssembly proposal [29] add secret types and instructions for constant-time cryptography. WASI-Crypto [18] lets Wasm code call the host’s native libraries and accelerators; our design instead keeps cryptography inside Wasm and needs no special API. Denis’s benchmarks [19] show that pure-Wasm AES-128-GCM reaches 351 Mb/s on the Fastly platform, slower than the AEGIS and HiAE ciphers on several content delivery platforms, and that on Wasmtime hand-optimized ChaCha20-Poly1305 reaches 492 MiB/s, whereas AES-128-GCM reaches 46–90 MiB/s. We measure how such stand-alone differences translate into the CPU time and goodput of QUIC. SIMD acceleration of cryptography. Our kernels adapt established SIMD techniques to the restrictions of WASMSIMD. Bitsliced AES-GCM [15] and vectorized ChaCha20 [16] parallelize each cipher along its computational structure, and HACL×N [30] generalizes the vectorization of ChaCha20 and Poly1305 to 128-, 256-, and 512-bit vectors. Käsper and Schwabe’s bitsliced AES already processes eight blocks in 128-bit registers on x86-64. Fixslicing [17] arranges the state so that repeated ShiftRows computations can be omitted, reducing the operation count of the linear layer by 52% on 32-bit platforms compared with the previously fastest bitsliced implementation. We combine the eight-block structure of the former with the fixsliced linear layer of the latter, which avoids repeated byte permutations.

4

A Pure-Wasm QUIC Stack

Our pure-Wasm QUIC stack runs QUIC, TLS, and cryptography in a single Wasm module without native libraries. We base it on Quinn [20], whose standard configuration relies on the tokio asynchronous runtime and on the assemblyoptimized ring library [21] and therefore does not compile for WASI 0.3 without modification. We instead use quinn-proto, Quinn’s sans-I/O QUIC state machine, and drive it with our own event loop over the asynchronous send and receive functions of wasi:sockets and the timers of wasi:clocks. All QUIC processing runs inside the asynchronous export of wasi:cli/run, and the build target is wasm32-wasip3. The event loop keeps one receive outstanding at all times and yields to the host only when no datagram awaits processing. It then waits until a receive, a send, or a timer completes. Each send or receive call handles a single datagram. For cryptography, we use the pure-Rust RustCrypto [22] through rustls-rustcrypto [23] rather than a Wasm port of ring. Ports such as ring-wasi [24] make ring available in extended environments such as WASIX, but its native assembly optimizations do not carry over to Wasm. RustCrypto contains no assembly and keeps all cryptography within standard WASI 0.3; we optimize it with explicit WASM-SIMD kernels. We also added QUIC header protection and Initial-packet encryption, which the provider did not previously support. 4.1

Evaluated Configurations

We compare six builds, each with two AEADs, ordered so that each successive pair isolates one source of the gap between Wasm and native (Figure 1). In every configuration, Initial packets use AES-128-GCM. Wasm-Base does not use WASM-SIMD and serves as the baseline. Wasm-AutoVec enables WASM-SIMD and relies solely on compiler auto-vectorization. Wasm-HandVec adds the explicit kernels of Section 7. The MACs remain scalar (Section 7.3). Native-Port is the Wasm-HandVec code built natively with the native socket API. It keeps 128-bit SIMD and uses no kernel offloads, so the step from Wasm-HandVec isolates the cost of the Wasm execution environment. Native-Opt extends Native-Port with AVX2 (256-bit SIMD), AES-NI (dedicated AES instructions), and the kernel offloads GSO and Generic Receive Offload (GRO), which process multiple UDP datagrams per system call. The step from Native-Port isolates host features that Wasm cannot use. Native-Quinn is the official Quinn on tokio and ring, the fastest native configuration in our evaluation. The step from Native-Opt isolates differences in implementation maturity.

5

Experimental Methodology

We measure receiver-side goodput and CPU time for 1-GiB bulk transfers between two hosts connected directly by 10GbE (Table 1). The server sends 1 GiB of application data to the client. Let 𝐵 be the number of bytes delivered to the receiving application without duplication and 𝑡 the transfer time in seconds; goodput is 𝐺 = 8𝐵/(106 𝑡) Mb/s. CPU time is the task-clock of all threads of the receiving process, measured with Linux perf stat and normalized to ms/GiB. 4

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

Wasm

Native-Port

Native-Opt

Base / AutoVec / HandVec

128-bit SIMD

AVX2 / AES-NI kernel offloads

quinn-proto

quinn-proto

quinn-proto

Quinn

rustls + rustls-rustcrypto

rustls + rustls-rustcrypto

rustls + rustls-rustcrypto

rustls

RustCrypto

RustCrypto

RustCrypto

Event loop

Event loop

Event loop

Tokio

wasi:sockets waitable set

std::net::UdpSocket libc::poll

quinn-udp GSO / GRO

quinn-udp GSO / GRO

A Preprint

Native-Quinn

ring

Wasmtime Ubuntu 24.04.3 / Intel X540-AT2 (10GbE)

Figure 1: Evaluated stacks and the receive path. The Wasm column combines three configurations. Blue blocks indicate components we implemented or extended. Table 1: Testbed. Goodput and CPU time are each measured over 20 runs, and CPU profiles are sampled at 4,000 Hz over 5 runs. The receiving process is pinned to CPUs 6–9. Wasmtime runs with -S inherit-network -S udp -S p3 -W component-model-async, plus --profile=perfmap when profiling. MTU: maximum transmission unit. Receiver

Sender

CPU Memory Network card OS

Ryzen 9 5900X 32 GiB Intel X540-AT2 Ubuntu 24.04.3

Core i9-12900K 16 GiB Intel X550 Ubuntu 26.04.1

Link OS kernel Buffers Software QUIC Protocol

Direct 10GbE connection Linux 7.0.0-31-generic, performance CPU governor Socket 8/32 MiB (default/max), backlog 30,000 Wasmtime 49.0.2, rustc 1.100.0-nightly, perf 7.0.14 quinn-proto 0.11.16, rustls 0.23.42, rustls-rustcrypto 0.0.2-alpha CUBIC congestion control [40], MTU 1,500 bytes

Receiver focus. We measure the receiver because receiver-side processing limits the data rate of QUIC on fast links [14]. ChaCha20 and the CTR part of AES-128-GCM generate the same keystream for encryption and decryption, so we expect our kernels to cost about the same on the sender; we do not evaluate Wasm senders. Socket buffers. We enlarged the socket buffers (Table 1) so that packet drops would not mask CPU limits. With the default UDP receive buffer, overflow dropped packets at the receiving socket, and QUIC congestion control then lowered the sending rate before the receiver reached its CPU limit. With the enlarged buffers, preliminary measurements showed no overflow. Sender. Every experiment uses Native-Quinn as the sender so that the sender never limits receiver goodput. Pairing each receiver with a sender of the same configuration would couple a slow receiver with a similarly slow sender and confound their limits. The sender’s CPU utilization is 6–26% in the Wasm measurements and at most 52% with Native-Port and Native-Opt. It approaches saturation (85–89%) only with Native-Quinn and ChaCha20-Poly1305.

5

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

Table 2: Transfer time for 1 GiB at the measured goodput (8 589.9 Mb/𝐺) compared with the receiver CPU time per GiB. Goodputs other than those of Wasm-Base and Wasm-HandVec are the rounded values shown in Figure 3; the last column is derived from these numbers. Algorithm

Build

Goodput (Mb/s)

Transfer time (s)

CPU time (s)

CPU/transfer

AES-128GCM

Wasm-Base Wasm-AutoVec Wasm-HandVec Native-Port Native-Opt Native-Quinn

612.4 620 988.1 1,235 5,131 9,081

14.03 13.85 8.69 6.96 1.67 0.95

14.48 14.31 9.09 6.42 1.14 0.90

1.03 1.03 1.05 0.92 0.68 0.95

ChaCha20Poly1305

Wasm-Base Wasm-AutoVec Wasm-HandVec Native-Port Native-Opt Native-Quinn

1,493.8 1,727 1,965.1 2,514 3,994 7,345

5.75 4.97 4.37 3.42 2.15 1.17

6.14 5.36 4.73 2.84 1.60 1.11

1.07 1.08 1.08 0.83 0.74 0.95

Table 3: Baseline (Wasm-Base) receiver goodput and CPU time per GiB. The non-crypto column is the total minus the crypto column. Algorithm AES-128-GCM ChaCha20-Poly1305

Goodput (Mb/s)

Total (ms/GiB)

crypto

non-crypto

crypto share

612.4 1,493.8

14,483 6,142

11,768 3,403

2,715 2,739

81.3% 55.4%

Is the receiver CPU-bound? The Wasm receivers are CPU-bound, so their goodput is inversely proportional to CPU time; the native receivers are not. Table 2 compares the time needed to transfer 1 GiB at the measured goodput with the receiver CPU time per GiB. For all three Wasm builds and both algorithms, CPU time exceeds transfer time by 0.35–0.46 s, so the guest thread is busy throughout the transfer. The nearly constant excess suggests a fixed per-process cost of roughly 0.4 s, such as module compilation, that counts toward CPU time but not transfer time. For Native-Port and Native-Opt, CPU time is only 68–92% of transfer time, so something other than receiver CPU limits their goodput (Sections 8.4 and 9). Profile classification. We attribute CPU time to processing categories by matching the symbol name of each profile sample, and where necessary its dynamic shared object (DSO) name, against regular expressions. Just-in-time (JIT) compiled code from Wasmtime [26] is mapped to symbols via perfmap, kernel-space symbols are resolved as well, and shares are weighted by the sampling period. Of our nine categories, Table 4 omits ack-loss (acknowledgment, loss detection, and congestion control), which stays below 4 ms/GiB in every configuration, and merges QUIC state updates and frame/header encoding and decoding into quic-proto; totals include all nine. Because categories are inferred from names, some samples may be misclassified. Our crypto, copy, and socket-io map onto the cryptography, memory copy, and socket I/O categories of Spies et al. [2], and the sum of the remaining categories maps onto their other.

6

Profiling the Baseline

Cryptography dominates the receiver CPU time of the non-SIMD baseline, accounting for 81.3% with AES-128-GCM and 55.4% with ChaCha20-Poly1305 (Table 3). These shares make cryptography the first target for acceleration. The difference between the two algorithms lies almost entirely in cryptography. Non-cryptographic CPU time is nearly identical (2,715 and 2,739 ms/GiB), as expected because the number of packets and QUIC processing steps per GiB does not depend on the algorithm. The cryptographic CPU time of AES-128-GCM is 3.46 times that of ChaCha20-Poly1305, and correspondingly ChaCha20-Poly1305 reaches 1,493.8 Mb/s, 2.44 times the 612.4 Mb/s of AES-128-GCM. AES-128-GCM therefore has the most to gain.

6

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

(a) ChaCha20 𝐵0

𝑥0

𝑥1

···

𝑥15

𝐵1

𝑥0

𝑥1

···

𝑥15

𝐵2

𝑥0

𝑥1

···

𝑥15

𝐵3

𝑥0

𝑥1

···

𝑥15

interleave into lanes

const key1 key5 𝑛0

const key2 key6 𝑛1

𝐵1

𝐵2

𝐵3

𝑅0

𝑥0

𝑥0

𝑥0

𝑥0

𝑅1

𝑥1

𝑥1

𝑥1

𝑥1

.. .

State matrix (64 bytes) const © key 0 ­ ­ key4 « ctr

𝐵0

𝑅15

𝑥15

𝑥15

𝑥15

𝑥15

Counter

𝑐

𝑐+1

𝑐+2

𝑐+3

u32

u32

u32

u32

const key3 ª® key7 ® 𝑛2 ¬

one v128 (4× u32): one lane per state matrix

8× v128

(b) AES-128 with fixslicing 𝐵0 𝐵1

A Preprint

transpose

𝑅0

𝐵0,0 𝐵1,0 𝐵2,0 𝐵3,0 𝐵4,0 𝐵5,0 𝐵6,0 𝐵7,0

𝑅1

𝐵0,1 𝐵1,1 𝐵2,1 𝐵3,1 𝐵4,1 𝐵5,1 𝐵6,1 𝐵7,1

.. .

.. .

𝐵7

𝑅7

𝐵0,7 𝐵1,7 𝐵2,7 𝐵3,7 𝐵4,7 𝐵5,7 𝐵6,7 𝐵7,7 𝐵𝑖, 𝑗 : bit plane 𝑗 of block 𝑖 Boyar–Peralta circuit (XOR/AND)

AES S-box 256-entry table lookup 𝑦 = 𝑆[𝑥]

replaced by 𝑥0 . . . 𝑥7

Top linear layer XOR

Nonlinear layer AND/XOR

Bottom linear layer XOR/XNOR

𝑦0 . . . 𝑦7

Figure 2: Data layouts of the SIMD cryptographic kernels. (a) ChaCha20: the words of four blocks are interleaved across lanes. (b) AES-128: eight blocks are transposed into bit planes.

7

Accelerating Authenticated Encryption with WASM-SIMD

We adapt known parallelization techniques [15–17] to the instruction constraints of WASM-SIMD. For AES, we widen a bit-level state layout to 128-bit vectors; for ChaCha20, we combine block-level parallelism with byte shuffles that compensate for the missing rotate instruction. 7.1

ChaCha20 Kernel

Our ChaCha20 kernel processes four blocks at once, exploiting the independence of ChaCha20 blocks [16]. ChaCha20 repeatedly applies ARX operations to a 4 × 4 state of sixteen 32-bit words. On the main path, each 128-bit register holds the word at the same position in four blocks (Figure 2(a)). Only the block counter differs between lanes, initialized as u32x4(𝑐, 𝑐 + 1, 𝑐 + 2, 𝑐 + 3). Sixteen v128 registers thus hold the entire state of four blocks, and the ten double rounds are fully unrolled without branches. When fewer than four blocks remain, a row-vector layout places the four words of each state row in one v128. Byte shuffles replace two of the four rotations, cutting each from three instructions to one. Without a lane-wise vector rotate, a rotation takes two shifts and an OR. Of the rotation amounts in the ChaCha20 double round (16, 12, 8, and 7 bits), the 16- and 8-bit rotations are byte-aligned, so we implement them with i8x16.shuffle. The 12- and 7-bit rotations still use shifts and ORs.

7

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

Wasm

Native

AES-128-GCM ChaCha20-Poly1305

1,965

1,727

WasmAutoVec

1,235

WasmBase

988

0

620

2,000

1,494

5,131

3,994

×1.32 SIMD kernels (this work)

4,000

2,514

×1.28 execution environment

612

Goodput (Mb/s)

×1.59 available features

8,000

7,345

9,081

×1.84 implementation maturity

10,000

6,000

A Preprint

WasmHandVec

NativePort

NativeOpt

NativeQuinn

Figure 3: Receiver-side goodput for 1-GiB transfers over the 10GbE link. Bars show the mean of 20 runs per configuration, and error bars show 95% confidence intervals based on the 𝑡 distribution. The sender is Native-Quinn for all configurations. The x-axis labels correspond to the configurations in Figure 1. The ratios in the figure refer to ChaCha20-Poly1305.

7.2

AES-128 Kernel

Our AES-128 kernel widens RustCrypto’s 32-bit fixsliced implementation [17] to 128-bit vectors so that eight registers process eight blocks in parallel. Bitslicing is necessary because WASM-SIMD has no AES instructions and cannot directly index a 256-entry S-box. The 32-bit implementation holds the state of two blocks in eight 32-bit words; we widen each word to four lanes, so eight v128 registers hold eight blocks (Figure 2(b)). The S-box is computed with the Boyar–Peralta circuit [39], and the per-round changes of the state layout are folded into the linear layer, so only a final layout correction remains instead of repeated ShiftRows. Unlike auto-vectorized code, the kernel explicitly implements the input/output transposition and the round operations; it shares the existing key schedule. It covers AES-128 encryption, which suffices for CTR mode in both directions; AES-256 is not implemented. The kernel is constant-time at the algorithmic level: it uses no secret-dependent branches or table lookups. It achieves this within standard WASM-SIMD, without extensions such as Constant-time WebAssembly [29]. Whether the JIT-compiled code preserves this property is a separate question (Section 9). 7.3

Scalar MAC Components

The MACs, GHASH and Poly1305, remain scalar because our WASM-SIMD prototypes of both were no faster than 64-bit scalar multiplication in preliminary experiments. The 64-bit multiplications these MACs need do not map efficiently to WASM-SIMD on our platform, and decomposing them into 32-bit multiplications increases both the number of multiplications and the data rearrangement across lanes. As a result, the MAC accounts for about 40% of the cryptographic CPU time of Wasm-HandVec with AES-128-GCM and about 50% with ChaCha20-Poly1305. WASM-SIMD does provide widening multiplications (i64x2.extmul_low_i32x4_u and its high counterpart), so multi-block Poly1305 with narrow limbs and 32-by-32-bit products, as in HACL×N [30], may fare better than our prototypes; we leave this to future work.

8

Evaluation

Our kernels raise Wasm goodput substantially, yet a wide gap to native remains. Figure 3 shows receiver goodput for each configuration, and Table 4 and Figure 4 break down receiver CPU time by category.

8

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

Table 4: Breakdown of receiver CPU time by category (ms/GiB). Total is the mean CPU time over 20 runs; each category is the total multiplied by that category’s share, averaged over 5 CPU profiles. crypto: cryptography; copy: memory copies; socket-io: socket processing; runtime: Wasmtime runtime processing; alloc: memory allocation and management; quic-proto: QUIC state updates and frame/header encoding and decoding; other: samples matching no category. The total also includes the omitted ack-loss category. The last column is crypto divided by total. Differences quoted in the text are computed from unrounded values. Algorithm

Build

crypto copy socket-io runtime alloc quic-proto other

AES-128GCM

Wasm-Base 11,768 Wasm-AutoVec 11,598 Wasm-HandVec 6,423 Native-Port 5,404 Native-Opt 534 Native-Quinn 184

Wasm-Base Wasm-AutoVec ChaCha20- Wasm-HandVec Poly1305 Native-Port Native-Opt Native-Quinn

3,403 2,631 2,004 1,804 976 495

38 37 38 27 14 37

441 443 423 209 36 89

281 285 302 0.0 0.5 0.0

593 589 591 22 24 22

322 1,038 14,483 319 1,033 14,306 303 1,005 9,089 156 606 6,424 141 389 1,138 170 399 902

81.3 81.1 70.7 84.1 46.9 20.4

38 33 34 29 20 36

423 439 425 203 36 71

291 284 287 0.0 0.1 0.0

584 594 585 22 23 19

331 1,071 315 1,057 319 1,073 161 618 145 400 153 331

55.4 49.1 42.4 63.6 61.0 44.8

AES-128-GCM Wasm

15.0

14.5

Wasm 7

14.3

12.5 10.0 7.5

9.1 6.4

5.0 2.5 0.0

Wasm- Wasm- Wasm- NativeBase AutoVec HandVec Port

6,142 5,355 4,726 2,837 1,599 1,106

ChaCha20-Poly1305 Native

1.1

0.9

NativeOpt

NativeQuinn

Receiver CPU time (s/GiB)

Receiver CPU time (s/GiB)

17.5

Total crypto (%)

6 5

Native

6.1 5.4

other copy quic-proto alloc runtime socket-io crypto

4.7

4 3

2.8

2

1.6 1.1

1 0

Wasm- Wasm- Wasm- NativeBase AutoVec HandVec Port

NativeOpt

NativeQuinn

Figure 4: Receiver CPU time per GiB by category, drawn from Table 4. Numbers above the bars are totals in s/GiB. Each SIMD step shrinks the cryptographic part of the Wasm builds, whereas alloc and runtime nearly vanish only in the native builds. 8.1

Gains from WASM-SIMD

WASM-SIMD cuts cryptographic CPU time while leaving the other categories nearly unchanged (Table 4). From Wasm-Base to Wasm-HandVec, goodput rises by 61.34% with AES-128-GCM and by 31.55% with ChaCha20Poly1305. Auto-vectorization helps ChaCha20-Poly1305 but barely helps AES-128-GCM: Wasm-AutoVec raises goodput over Wasm-Base by 15.60% and 1.28%, respectively. ChaCha20 applies regular ARX operations to 32-bit words, which the compiler maps to identical operations across lanes; auto-vectorization alone cuts its cryptographic CPU time by 22.7%. AES in Wasm-Base, in contrast, already exploits bit-level parallelism within each word: the RustCrypto aes crate uses a table-free fixsliced implementation for 32-bit platforms that spreads two blocks across eight 32-bit words and computes the S-box with logic operations alone. Its linear layer consists of bit swaps and rotations whose shift amounts differ from word to word, leaving the compiler little to merge across lanes. GHASH, for its part, emulates carry-less multiplication with constant-time 64-bit integer multiplication; WASM-SIMD has no carry-less multiplication, and even its lane-wise i64x2.mul expands into multiple instructions on x86-64. Explicit kernels help both algorithms, and for AES-128-GCM they succeed where auto-vectorization fails, showing that the state layout and operations must be designed explicitly for WASM-SIMD. Relative to Wasm-AutoVec, the AES-128 kernel raises goodput by 59.31% and cuts cryptographic CPU time by 44.6%, whereas the ChaCha20 kernel raises goodput by 13.79% and cuts cryptographic CPU time by 23.8%. As Amdahl’s law predicts, the AES-128-GCM 9

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

Table 5: Decrease in receiver CPU time (ms/GiB) between successive configurations with ChaCha20-Poly1305, by category, computed from the unrounded values behind Table 4. Negative values are increases. Columns may not sum exactly because of rounding. Wasm-HandVec → Native-Port

Native-Port → Native-Opt

Native-Opt → Native-Quinn

crypto copy socket-io runtime alloc quic-proto other ack-loss

200 5 222 287 563 158 455 1

828 9 167 −0.1 −0.7 17 218 0.0

480 −15 −35 0.1 4 −8 69 −0.6

Total decrease Goodput ratio CPU-time ratio

1,889 1.28 1.67

1,238 1.59 1.77

494 1.84 1.45

gain is larger because cryptography is both a larger share of its CPU time and reduced by a larger fraction. For ChaCha20-Poly1305, auto-vectorization had already cut cryptographic CPU time by 22.7%, leaving less for the explicit kernel to remove. 8.2

Cipher Choice in Pure Wasm

ChaCha20-Poly1305 remains the faster algorithm in pure Wasm even after our kernels: Wasm-HandVec reaches 1,965.1 Mb/s with it but 988.1 Mb/s with AES-128-GCM, a factor of 1.99. The factor shrinks from 2.44 at baseline because our kernels accelerate AES more than ChaCha20 in relative terms. This result, together with the 81.3% cryptographic share of the AES baseline, is consistent with Denis’s finding that pure-Wasm AES-GCM is slow [19]. Without hardware AES, ChaCha20-Poly1305 is the better choice for QUIC in our stack. 8.3

Comparison Across Configurations

The fastest native configuration still far outpaces the fastest Wasm one: Native-Quinn delivers 9.19 times the goodput of Wasm-HandVec with AES-128-GCM and 3.74 times with ChaCha20-Poly1305. With ChaCha20-Poly1305, WASM-SIMD raises Wasm goodput from 20.3% (Wasm-Base) to 26.8% (Wasm-HandVec) of Native-Quinn with the same cipher. Spies et al. [2] instead normalized by the fastest native configuration regardless of cipher; by that measure, which here is Native-Quinn with AES-128-GCM, Wasm-Base and Wasm-HandVec reach 16.4% and 21.6%. Their measurements, however, were taken at the sender over a loopback path, so the two results are not directly comparable. We decompose the ChaCha20-Poly1305 gap into three successive goodput ratios, each isolating one factor (Table 5): 1.28 from Wasm-HandVec to Native-Port, 1.59 from Native-Port to Native-Opt, and 1.84 from Native-Opt to Native-Quinn. The first ratio, 1.28, reflects the cost of the Wasm execution environment, which lies mostly outside cryptography. Because Wasm-HandVec and Native-Port share their code and SIMD width, their cryptographic CPU times are close: 2,004 and 1,804 ms/GiB, about 10% apart. Wasm-HandVec instead spends more in every non-cryptographic category (Figure 4 and Table 5). Of the 1,889 ms/GiB difference in total CPU time, memory allocation accounts for 563 ms/GiB, other for 455, runtime processing for 287, socket processing for 222, cryptography for 200, and QUIC protocol processing for 158. Memory allocation and runtime processing, both nearly absent in the native builds, explain nearly half of the difference. The second ratio, 1.59, reflects host features that Wasm cannot use: wider SIMD and kernel offloads. Of the 1,238 ms/GiB decrease, cryptography accounts for 828 ms/GiB, which with ChaCha20-Poly1305 can come only from AVX2, followed by other (218) and socket processing (167), the expected effect of GSO/GRO. Wasm cannot obtain the latter gain today: the UDP API of WASI 0.3 handles one datagram per send or receive call [27], and Wasmtime 49.0.2 likewise issues one system call per datagram. Narrowing this gap requires WASI to expose host-side batching such as GSO/GRO, although, as Jaeger et al. [8] found natively, offloads also need matching batched I/O in the application to pay off.

10

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

The third ratio, 1.84, stems almost entirely from the cryptographic libraries of the two native implementations. Native-Quinn spends 495 ms/GiB on cryptography, about half of the 976 ms/GiB of Native-Opt, and cryptography accounts for 480 of the 494 ms/GiB decrease in total CPU time (Table 5). The ring library of Native-Quinn and the RustCrypto library of Native-Opt differ in their implementations and assembly optimizations, which is the likely cause. Making a library available on a platform and making it fast there are therefore separate problems. 8.4

Estimating Further Gains with Amdahl’s Law

Amdahl’s law [41] lets us estimate how much of the remaining gap cryptography alone could close. Our kernels change mainly cryptographic CPU time, unlike optimizations such as batched I/O that change socket-io, alloc, and copy at once, so we can model their effect while holding other costs constant. Let 𝑇 be the receiver CPU time per GiB, 𝑐 the share of cryptography in 𝑇, and 𝑟 the fraction by which cryptographic time is reduced. The new CPU time is 𝑇 ′ = 𝑇 − 𝑟 𝑐 𝑇, so the predicted speedup is 1 𝑇 . (1) 𝑆= ′ = 𝑇 1−𝑐𝑟 Because the Wasm receivers are CPU-bound (Table 2), goodput is inversely proportional to 𝑇, and the predicted goodput is 𝐺 ′ = 𝑆 𝐺. The model reproduces the measured gains from Wasm-AutoVec to Wasm-HandVec within 2%. It predicts speedups of 1.567 for AES-128-GCM and 1.133 for ChaCha20-Poly1305, against measured 1.593 and 1.138. Non-cryptographic CPU time stays nearly constant, changing from 2,708 to 2,665 ms/GiB with AES-128-GCM and from 2,724 to 2,722 ms/GiB with ChaCha20-Poly1305. This agreement is a self-consistency check, since 𝑐 and 𝑟 come from the same profiles, not an independent validation of the category classification. Even with the cryptographic CPU time of Native-Opt, which shares the codebase but uses wider SIMD and AES instructions, Wasm goodput would reach only about one third of Native-Quinn. We substitute NativeOpt’s cryptographic CPU time into Wasm-HandVec and keep non-cryptographic time constant. For ChaCha20Poly1305, 𝑐 = 2004/4726 = 0.424 and 𝑟 = (2004 − 976)/2004 = 0.513, so Equation (1) predicts a speedup of 1/(1 − 0.424 × 0.513) = 1.28 and a goodput of 2,511 Mb/s: 62.9% of Native-Opt and 34.2% of Native-Quinn with the same cipher. For AES-128-GCM, the prediction is 2,807 Mb/s, or 54.7% of Native-Opt and 30.9% of Native-Quinn. In CPU time, the predicted 3,698 ms/GiB of Wasm-HandVec with ChaCha20-Poly1305 is still 2.3 times the 1,599 ms/GiB of Native-Opt; with AES-128-GCM the factor is 2.8. These estimates are conditional, not upper bounds. Reducing non-cryptographic costs could raise Wasm goodput further, whereas Native-Opt-level cryptography is out of reach within WASM-SIMD, which offers neither AVX2-width vectors nor AES instructions. Because the native receivers are not saturated (Table 2), comparisons with their measured goodput also understate the remaining gap. The non-cryptographic costs that remain point to memory allocation, runtime processing, and the use of host features as the next optimization targets. The large other category needs finer analysis before its cost can be attributed to specific causes.

9

Discussion and Limitations

Strength of the baseline. Our AES gain is measured against RustCrypto’s default wasm32 path, which may not be the strongest scalar baseline. That path is a fixsliced AES with 32-bit words and two blocks per call. On 64-bit targets the same crate selects a variant with 64-bit words and four blocks, which could be faster in Wasm because Wasm has native 64-bit integer operations; we have not evaluated it. The 61.34% gain for AES-128-GCM could therefore be smaller against a 64-bit scalar variant. Likewise, Wasm-AutoVec reflects what the compiler achieves on this code, not what any auto-vectorizer could achieve. Scope of the cipher comparison. Our cipher comparison applies to our RustCrypto-based stack, not to AES-GCM in Wasm in general. In our stack, GHASH is scalar and the AES kernel covers only AES-128. The results do not show that AES-GCM is intrinsically slower than ChaCha20-Poly1305 in Wasm and say nothing about AES-256-GCM; a faster GHASH could narrow the gap. Native configurations are not CPU-bound. The goodput ratios between Wasm and native understate the efficiency gap because the native receivers are not CPU-bound. Native-Port and Native-Opt use only 68–92% of the transfer time, and with Native-Quinn and ChaCha20-Poly1305 the sender reaches up to 88.8% CPU utilization and may partly

11

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

limit goodput. Accordingly, the first two CPU-time ratios in Table 5 (1.67 and 1.77) exceed the corresponding goodput ratios (1.28 and 1.59). We report goodput ratios in Section 8 because goodput is what an application observes. Fixed per-process costs. Costs incurred once per process inflate our 1-GiB Wasm figures. The nearly constant 0.35–0.46 s excess of CPU time over transfer time in the Wasm builds suggests a fixed cost of roughly 0.4 s, such as module compilation, similar in magnitude to the runtime category (281–302 ms/GiB). If so, the runtime category and part of other would amortize over longer transfers, and the steady-state gap to native would be somewhat smaller. We have not verified this with longer transfers. Statistical reporting. The category breakdown is less certain than the goodput measurements. Goodput is averaged over 20 runs with 95% confidence intervals (Figure 3), whereas the breakdown averages 5 profiles without confidence intervals, so differences of a few percent in a single category should not be over-interpreted. The name-based classification may also misclassify samples. In particular, other includes unmatched OS-kernel processing and accounts for 22.7% of total CPU time in Wasm-HandVec with ChaCha20-Poly1305; breaking it down is necessary to identify which costs are specific to Wasm. Platform and workload. Our results cover one hardware platform, one runtime, and one workload: 1-GiB bulk transfers between high-performance x86-64 machines running Wasmtime 49.0.2 over a direct, lossless, low-latency link. The benefit of SIMD depends on the number of vector execution units, the clock frequency, and the cache hierarchy, so validation is needed on Internet of Things (IoT) and edge devices, on other instruction sets and runtimes, and over paths that emulate real networks. For short connections, the handshake and header protection account for a larger share of processing, so the gains may be smaller. The kernels also process packet-sized inputs of up to roughly 1,400 bytes, for which the handling of the last few blocks of each packet matters [35]. Given the performance difference between the experimental rustls-rustcrypto and ring, evaluation with multiple QUIC implementations is also needed. Runtime dependence. The absolute gains depend on how the runtime lowers WASM-SIMD. Our byte-shuffle rotations and 128-bit kernels rely on Wasmtime lowering i8x16.shuffle and other vector instructions to efficient x86-64 instructions. Other runtimes, such as browser engines, and other architectures may lower them differently, although the design principles carry over. Single guest thread and packet size. Our setup measures per-core efficiency at a 1,500-byte MTU and likely understates the importance of the kernels at larger MTUs. We run one connection on one guest thread; scaling across cores, for example with one connection per core, is orthogonal to this efficiency. A larger MTU would amortize per-packet non-cryptographic costs [34] and likely raise the share of cryptography, making the kernels more important; we did not test this. Host-provided cryptography. Our results set the bar that host-provided cryptography such as WASI-Crypto would have to beat, but we did not measure it. Such an interface would exploit AES instructions and wider vectors but incur guest–host transitions and memory copies for every packet; a direct comparison is future work. Side channels. Whether the constant-time design survives JIT compilation remains unverified. The kernels avoid secret-dependent branches and table lookups, but future work must evaluate resistance to timing attacks and explore integration with Constant-time WebAssembly [29]. Practical relevance of the absolute numbers. Our best Wasm configuration, at about 2 Gb/s, remains far below the 10GbE line rate and reaches 27% of Native-Quinn with the same cipher. This paper contributes a quantified path toward closing the gap, not a claim that it has been closed.

10

Conclusion and Future Work

Explicit WASM-SIMD kernels substantially accelerate a pure-Wasm QUIC stack, but cryptographic acceleration alone cannot close the gap to native. Our eight-block fixsliced AES and four-block ChaCha20 kernels raise goodput in a WASI 0.3 QUIC stack by 61.34% and 31.55% over the non-SIMD baseline, and the comparison with autovectorization shows that state layouts and operations must be designed explicitly for the constraints of WASM-SIMD. After optimization, ChaCha20-Poly1305 delivers 1.99 times the goodput of AES-128-GCM, confirming end to end the importance of cipher choice suggested by stand-alone benchmarks [19]. Profiling and Amdahl’s law predict that, even with Native-Opt-level cryptography and unchanged non-cryptographic costs, goodput would reach only 34.2%

12

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

(ChaCha20-Poly1305) and 30.9% (AES-128-GCM) of Native-Quinn with the same cipher. The next targets are therefore memory allocation, runtime overhead, and efficient use of host features such as batched sends and receives [13]. The scalar components and untested baselines define the immediate future work. GHASH, Poly1305, and the single-block AES-ECB encryption for header protection remain scalar; the MACs alone account for 40–50% of the cryptographic CPU time of Wasm-HandVec, and our SIMD prototypes did not reduce their cost, so their arithmetic structure must be reconsidered. Experiments that would strengthen our conclusions include a 64-bit fixsliced scalar baseline, longer transfers, a comparison with WASI-Crypto [18] that accounts for guest–host transitions and copies, and an ablation of the individual Native-Opt features (AVX2, GSO/GRO, and AES-NI).

Acknowledgments This work was supported by the FORWARD commissioned research program of the Ministry of Internal Affairs and Communications (MIC), Japan (JPMI260720003).

References [1] P. Gackstatter, P. A. Frangoudis, and S. Dustdar. Pushing serverless to the edge with WebAssembly runtimes. In Proc. IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid), pages 140–149, 2022. [2] B. Spies, C. Obermaier, and J. Ott. Exploring composable network stacks from isolated components with WebAssembly and QUIC. In Workshop on Internet of Things Management (manage-IoT), IEEE/IFIP Network Operations and Management Symposium (NOMS) Workshops, pages 1–7, 2025. https://doi.org/10.1109/ NOMS57970.2025.11073740. [3] J. Iyengar and M. Thomson. QUIC: A UDP-based multiplexed and secure transport. RFC 9000, May 2021. [4] A. Langley, A. Riddoch, A. Wilk, A. Vicente, C. Krasic, D. Zhang, F. Yang, F. Kouranov, I. Swett, J. Iyengar, J. Bailey, J. Dorfman, J. Roskind, J. Kulik, P. Westin, R. Tenneti, R. Shade, R. Hamilton, V. Vasiliev, W.-T. Chang, and Z. Shi. The QUIC transport protocol: Design and Internet-scale deployment. In Proc. ACM SIGCOMM, pages 183–196, 2017. [5] E. Chi, G. Wang, J. A. Halderman, E. Wustrow, and J. Wampler. Just add WATER: WebAssembly-based circumvention transports. In Free and Open Communications on the Internet (FOCI), no. 1, pages 22–28, 2024. [6] M. Kempf, N. Gauder, B. Jaeger, J. Zirngibl, and G. Carle. A quantum of QUIC: Dissecting cryptography with post-quantum insights. In Proc. IFIP Networking Conference, 2024. [7] M. Thomson and S. Turner. Using TLS to secure QUIC. RFC 9001, May 2021. [8] B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, and G. Carle. QUIC on the highway: Evaluating performance on high-rate links. In Proc. IFIP Networking Conference, 2023. [9] WebAssembly Community Group. WebAssembly SIMD proposal. https://github.com/WebAssembly/simd. [10] A. Haas, A. Rossberg, D. L. Schuff, B. L. Titzer, M. Holman, D. Gohman, L. Wagner, A. Zakai, and J. Bastien. Bringing the web up to speed with WebAssembly. In Proc. ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), pages 185–200, 2017. [11] WebAssembly Community Group. WASI: The WebAssembly system interface. https://wasi.dev/, 2024. [12] R. Szewczyk, K. Stonehouse, A. Barbalace, and T. Spink. Leaps and bounds: Analyzing WebAssembly’s performance with a focus on bounds checking. In Proc. IEEE International Symposium on Workload Characterization (IISWC), pages 256–268, 2022. [13] R. Aoyagi and Y. Okabe. Investigating send/receive overhead in Wasm-based QUIC and reducing it by batching. IPSJ SIG Technical Report, Internet and Operation Technology (IOT), Vol. 2026-IOT-75, No. 18, pages 1–8, 2026 (in Japanese). [14] X. Zhang, S. Jin, Y. He, A. Hassan, Z. M. Mao, F. Qian, and Z.-L. Zhang. QUIC is not quick enough over fast Internet. In Proc. ACM Web Conference (WWW), pages 2713–2722, 2024. [15] E. Käsper and P. Schwabe. Faster and timing-attack resistant AES-GCM. In Cryptographic Hardware and Embedded Systems (CHES), pages 1–17, 2009. [16] M. Goll and S. Gueron. Vectorization on ChaCha stream cipher. In Proc. International Conference on Information Technology: New Generations (ITNG), pages 612–615, 2014. [17] A. Adomnicai and T. Peyrin. Fixslicing AES-like ciphers: New bitsliced AES speed records on ARM-Cortex M and RISC-V. IACR Transactions on Cryptographic Hardware and Embedded Systems, 2021(1):402–425, 2021. 13

Accelerating QUIC Encryption in WebAssembly Using WASM-SIMD

A Preprint

[18] WebAssembly Community Group. WASI cryptography API proposal. https://github.com/WebAssembly/w asi-crypto. [19] F. Denis. WebAssembly cryptography benchmarks (gist foo.md). GitHub Gist, https://gist.github.com/ jedisct1/d472bded6e35cfcec01d1e858ff248df, 2026. Accessed October 11, 2026. [20] Quinn Developers. Quinn: Async-friendly QUIC implementation in Rust. https://github.com/quinn-rs/ quinn. [21] B. Smith. ring: Safe, fast, small crypto using Rust. https://github.com/briansmith/ring. [22] RustCrypto Developers. RustCrypto: Cryptographic algorithms written in pure Rust. https://github.com/R ustCrypto. [23] RustCrypto Developers. rustls-rustcrypto. https://github.com/RustCrypto/rustls-rustcrypto. [24] S. Akbary. Our precious: Cryptographic support for WASIX. Wasmer Blog, August 2023, https://wasmer.i o/posts/cryptographic-support-for-wasix. [25] E. Rescorla. The Transport Layer Security (TLS) protocol version 1.3. RFC 8446, August 2018. [26] Bytecode Alliance. Wasmtime: A fast and secure runtime for WebAssembly. https://wasmtime.dev/. [27] WebAssembly Community Group. WASI sockets proposal. https://github.com/WebAssembly/wasi-soc kets, 2024. [28] WebAssembly Community Group. WASI 0.3.0 (formerly Preview 3), released June 2026. https://github.com /WebAssembly/WASI. [29] WebAssembly Community Group. Constant-time WebAssembly. https://github.com/WebAssembly/con stant-time. [30] M. Polubelova, K. Bhargavan, J. Protzenko, B. Beurdouche, A. Fromherz, N. Kulatova, and S. Zanella-Béguelin. HACL×N: Verified generic SIMD crypto (for all your favourite platforms). In Proc. ACM Conference on Computer and Communications Security (CCS), 2020. [31] J. Protzenko, B. Beurdouche, D. Merigoux, and K. Bhargavan. Formally verified cryptographic web applications in WebAssembly. In Proc. IEEE Symposium on Security and Privacy (S&P), 2019. [32] C. Watt, J. Renner, N. Popescu, S. Cauligi, and D. Stefan. CT-Wasm: Type-driven secure cryptography for the web ecosystem. Proc. ACM on Programming Languages, 3(POPL), 2019. [33] S. Mukherjee, D. Lei, M. Ammar, and A. Saeed. Understanding QUIC’s throughput speedbumps. In Proc. Applied Networking Research Workshop (ANRW), 2025. https://doi.org/10.1145/3744200.3744780. [34] M. König, S. Rust, M. Zitterbart, and B. Scheuermann. Examining the heterogeneous throughput performance landscape of QUIC implementations. In Proc. IFIP Networking Conference, 2025. [35] K. Oku. AEAD and header encryption overhead in QUIC. Message to the IETF QUIC working group mailing list, June 18, 2020. https://mailarchive.ietf.org/arch/msg/quic/OnBhC4gCosmlU3VKoFk_jJnpeXU/. [36] Polymorph Components Developers. polymorph-tls: TLS implementations for WebAssembly components. https://github.com/polymorph-components/polymorph-tls. Accessed October 18, 2026. [37] Y. Nir and A. Langley. ChaCha20 and Poly1305 for IETF protocols. RFC 8439, June 2018. [38] M. Dworkin. Recommendation for block cipher modes of operation: Galois/Counter Mode (GCM) and GMAC. NIST Special Publication 800-38D, November 2007. [39] J. Boyar and R. Peralta. A small depth-16 circuit for the AES S-box. In Proc. IFIP International Information Security Conference (SEC), pages 287–298, 2012. [40] L. Xu, S. Ha, I. Rhee, V. Goel, and L. Eggert. CUBIC for fast and long-distance networks. RFC 9438, August 2023. [41] G. M. Amdahl. Validity of the single processor approach to achieving large scale computing capabilities. In Proc. AFIPS Spring Joint Computer Conference, pages 483–485, 1967.

14

Related documents

• Manageability of the QUIC Transport Protocol#131442
• A Binary and System Integrated Analysis Approach for Securing the QUIC Protocol#343418
• Applicability of the QUIC Transport Protocol#502673
• zk-ScalHard: Scalable and Hardware-Rooted Privacy-Preserving Authentication for Secure OTA Updates in Zonal SDVs#353013
• websecurity at uibk#1025380