Frank DENIS random thoughts.

AES gets swizzled

2026-07-16T00:00:00+02:00

There’s an old problem with AES when implemented in software: it’s either slow or insecure.

AES has a state of sixteen bytes, and a round has four steps:

SubBytes replaces every byte using the AES S-Box.
ShiftRows moves bytes to different columns.
MixColumns combines the four bytes in each column.
AddRoundKey XORs another sixteen-byte value.

And SubBytes is the annoying part, because it applies a random-looking permutation to every byte:

SBox(0x00) = 0x63
SBox(0x53) = 0xed
...

An obvious way to implement that is by using lookup tables.

But here’s the problem: the lookup indices are secret data, and accessing a cache line that was just accessed and is still in the cache is slightly faster than accessing other addresses.

Taking advantage of this, an adversary on the same machine can learn information about the secret indices. For example, DJB recovered AES keys from remote timings, and Osvik, Shamir, and Tromer demonstrated cross-process attacks against OpenSSL and disk encryption.

That was mostly solved on modern mobile, desktop, and server CPUs by adding AES instructions.

But old is new again. With new platforms such as WebAssembly, even when running on such CPUs, applications can’t use AES instructions, so they have to reimplement AES themselves. Sigh.

A common way to avoid using lookup tables is bitslicing: using a circuit of logical operations applied to a different representation of the AES state, where all the bits expected to follow the same circuit are packed together in a register.

It works very well in hardware, but in software, performance is generally still not great, especially compared to what CPU AES instructions can do.

But there’s a third option that’s surprisingly not well known and was originally described by Mike Hamburg in Accelerating AES with Vector Permute Instructions.

A lookup table inside a register

Modern CPUs, even when accessed via WebAssembly, include something nice: SIMD registers that contain 16 bytes or more.

A lot of instructions can be used with such registers, but a very common one, which (oh, joy!) is even accessible in WebAssembly, treats one 16-byte vector as a table and another as sixteen selectors:

table     = [t0, t1, t2, ... t15]
selectors = [ 3,  9,  0, ...   7]
result    = [t3, t9, t0, ...  t7]

A single instruction effectively performs sixteen lookups in parallel. The table is kept in a register, so there are no memory lookups, and (barring microarchitectural vulnerabilities) no side channels.

This is something that all CPUs with SIMD instructions support. On x86, it’s called PSHUFB, on ARM, TBL, and WebAssembly has a corresponding instruction called i8x16.swizzle, which any sane compiler can map directly to PSHUFB or TBL.

When selectors are between 0 and 15, the behavior is as expected, and the same across all targets.

Values outside that range are target-specific, which is important for WebAssembly (more about that later).

Turning 256 values into 16 by 16

The AES S-Box isn’t actually random. It’s defined as:

S(b) = A(inverse(b)) XOR 0x63

The byte is inverted in the AES finite field. Then a fixed linear bit transformation A and the constant 0x63 are applied. And the inverse of zero is defined as zero.

AES uses a finite field with 256 elements, commonly written GF(2^8). And the same field can be represented as a quadratic extension of a 16-element field:

GF(2^8) is isomorphic to GF(2^4)[t] / (t^2 + t + zeta)

With these binary encodings, field addition in both GF(2^8) and GF(2^4) is bitwise XOR.

Here zeta is chosen so that the quadratic polynomial is irreducible.

And here’s something interesting:

256 = 16 * 16

This is just a reversible change of coordinates.

And in the new representation, one byte becomes a pair of encoded four-bit field components, while addition and multiplication keep working as expected.

A linear input transformation produces those components:

lo = input & 0x0f
hi = input >> 4

encoded = lookup16(input_map_lo, lo) XOR lookup16(input_map_hi, hi)

See? The low and high nibble contributions can be looked up separately because the transform is linear.

With two permutations, we can transform all sixteen AES state bytes.

Inversion with small register tables

Hamburg’s nested-inversion construction reduces the nonlinear part of the field inverse to five small lookups:

k = low_nibble(encoded)
i = high_nibble(encoded)
j = k XOR i

ak  = lookup16(inverse_scaled, k)
iak = lookup16(inverse, i) XOR ak
jak = lookup16(inverse, j) XOR ak
io  = lookup16(inverse, iak) XOR j
jo  = lookup16(inverse, jak) XOR i

The stages use scaled and skewed representations, so treating every value as an ordinary nibble in one fixed GF(2^4) basis gives incorrect results.

So, two output tables apply the remaining factors, return to the normal AES byte basis, and apply the linear part of the S-Box affine map:

a = lookup16(output_u, io) XOR lookup16(output_t, jo)

a XOR 0x63 = AES_SBOX[input]

With the target-specific infinity handling described below, we get the correct S-Box value for every possible input byte. And we only need 16-element lookup tables. Each fits in a SIMD register. You see where this is going.

Folding the rest of the round

MixColumns is evaluated on the constant-free S-Box value a = A(inverse(input)).

It needs both a and a multiplied by 0x02 in the AES field (3a is also needed, but that’s just a + 2a).

Since that operation is linear, a second pair of output tables can produce the doubled value directly:

a2 = lookup16(output2_u, io) XOR lookup16(output2_t, jo)

Four fixed permutations gather the bytes after ShiftRows and arrange the MixColumns contributions:

m0 = permute(a2,       mix0)
m1 = permute(a XOR a2, mix1)
m2 = permute(a,        mix2)
m3 = permute(a,        mix3)

output = m0 XOR m1 XOR m2 XOR m3

How about the affine constant 0x63 we talked about earlier? Turns out that we can omit it.

A vector containing 0x63 in every byte is unchanged by ShiftRows and survives MixColumns because every output row’s coefficients XOR to one:

0x02 XOR 0x03 XOR 0x01 XOR 0x01 = 0x01

Just one final vector XOR restores 0x63.

We can finally AddRoundKey, which is a simple XOR.

To do all this, we only need 15 byte permutations:

Input transformation:          2
Nested inversion:              5
S-Box output and its double:   4
ShiftRows and MixColumns:      4
                              --
Total:                        15

Swizzling infinity

The inversion contains denominators that can be zero. So we need some kind of out-of-range selector to represent infinity.

The inverse tables map a zero denominator to 0x80. XORing that with a nibble can produce anything from 0x80 through 0x8f, but these values all represent the same infinity marker: bit 7 is set, while the low nibble doesn’t matter. When one of them selects from the next 16-byte table, the byte permutation returns zero.

And as mentioned previously, different targets treat out-of-range selectors differently.

Primitive	Out-of-range selector behavior
x86 `PSHUFB`	If selector bit 7 is set, the result is zero; otherwise the low nibble selects
AArch64 `TBL`	Every index above 15 returns zero
WebAssembly strict SIMD	Every index above 15 returns zero
WebAssembly relaxed SIMD	`0x10` to `0x7f` may return zero or use the low nibble; `0x80` to `0xff` returns zero

A selector between 0 and 15 or between 0x80 and 0xff produces the same output everywhere, even in WebAssembly.

And the circuit described above only produces selectors in 0x00 through 0x0f or 0x80 through 0x8f. So, we’re safe!

The default WebAssembly “strict” SIMD mode doesn’t map well to x86 instructions, so the generated code is pretty inefficient.

Fortunately, WebAssembly later introduced a relaxed-simd variant of the instruction that marks selectors in the 0x10 through 0x7f range as “don’t-care” values and lowers directly to a CPU instruction.

It’s a little sad that WebAssembly support is fragmented and relaxed SIMD isn’t supported everywhere yet, most notably in Safari. At least server runtimes such as Wasmer, WasmEdge, Wasmtime, and WAVM have supported it by default for a long time. And Safari will eventually catch up.

Is this technique worth it compared to lookup tables and bitslicing? It is. Compared to lookup tables, it guarantees constant-time execution. And compared to bitslicing, it doesn’t require bit-level representation changes and introduces less register pressure.

Most importantly, it’s a very good match for how some new AES-based ciphers such as AEGIS and HiAE operate. And we can finally have ciphers with half-decent performance on WebAssembly rumtimes without the WASI-Crypto extensions.

The best WebAssembly runtime may still be no runtime at all

2026-07-08T00:00:00+02:00

In 2023, I wrote that the best WebAssembly runtime may be no runtime at all.

To summarize: if you already have a WebAssembly module, translating it to C and compiling that C with a normal native compiler can be surprisingly hard to beat.

I expected that argument to get weaker over time, because WebAssembly runtimes keep improving. Their compilers have better register allocators, better lowering, better support for newer WebAssembly instructions, and more deployment polish than a small transpiler can reasonably have.

Then I ran the 2026 benchmark.

The 2026 WebAssembly benchmark has the full table for other runtimes.

And the WebAssembly-to-C path performed very well, but was beaten by new runtimes implementing the “wide arithmetic” WebAssembly proposal.

I was curious to see how the WebAssembly-to-C approach would work with if that proposal was implemented.

So, let’s compare:

Wasmer 7.1.0
Wasmtime 46.0.0
WABT wasm2c

For wasm2c, I added support for wide arithmetic, which was surprisingly trivial to implement. You can find my fork here.

The generated C code simply uses compiler carry intrinsics and C’s 128-bit integer type.

Note that I compiled the generated C with WABT’s Segue memory mode enabled, with zig cc -O3 -march=native, on the exact same libsodium benchmark suite as the previous runtime post.

Every build uses the lime1+simd128+wide_arithmetic feature set.

Oh, and before you ask: wasm2c supports memory protection using guard pages, like other runtimes.

The speed numbers

The numbers below are slowdowns relative to the native libsodium build. A value of 1.25x native means the benchmark took 25% more time than native code.

Lower is better.

The median is a tie with Wasmer. But the wasm2c executable used 0.887x as much time as Wasmer on the geomean, and 0.814x as much as Wasmtime.

The dumb C path survived the feature upgrade. Once the new arithmetic instructions were added, a normal C compiler could again produce code competitive with dedicated WebAssembly compilers.

Memory usage

I also measured peak resident set size with /usr/bin/time -v.

This is cold process RSS for one command invocation, using the median of fifteen runs. It includes the runtime executable, its startup state, JIT or compilation machinery used by that command, and anything else the process maps while running the benchmark.

Note that Wasmer and Wasmtime have a fixed cost that can be amortized if a service keeps the runtime alive and runs many modules or many calls.

Most of that difference is fixed engine overhead. The module itself costs very little.

If I subtract the RSS of an empty WASI module run through the same path, with a 64 MiB maximum linear memory like the benchmark build, only a couple of MiB remain:

At run time, with the WebAssembly code directly compiled to C, then to executable code, there’s no engine process to bring along.

No runtime is still a good choice

The generated output is portable C.

So, the deployment target no longer has to be “a platform with a WebAssembly runtime”. It can be any platform with a C compiler and enough libc support for whatever the module imports.

It also means the compiler is a choice.

You can compile the generated C with clang or gcc.

But you can also take advantage of modern C toolchains such as Fil-C to get memory safety on wasm64, or on wasm32 without depending on virtual-memory guard pages.

Or you can use a formally verified compiler such as CompCert for high assurance code generation.

I didn’t benchmark those toolchains. The point is that WebAssembly-to-C gives you that option, while a dedicated runtime doesn’t.

This is also why I remain impressed by Wasmer.

Wasmer also implements WASIX, which fills many of the POSIX-shaped gaps that plain WASI still leaves open. So, if your goal is to run existing applications in WebAssembly with fewer rewrites, this is the way to go, not WebAssembly-to-C or other options.

And Wasmtime implements the “Component Model”, that improves code separation and gives applications a typed interface boundary for composing pieces of WebAssembly. I have an intuition that the same thing can be achieved using WebAssembly-to-C by compiling components separately, but I didn’t think about it much.

Regardless WebAssembly-to-C is the wrong answer if you need dynamic loading of untrusted code without precompilation, runtime-level policy, preemption, fuel, component-model machinery, or one engine reused across many tenants.

It’s also the wrong answer if your deployment model depends on shipping one portable .wasm artifact and letting the destination machine choose how to run it.

But if you control the WebAssembly module, can precompile it, and don’t need runtime services, WebAssembly-to-C is very close to a no-brainer, especially with the addition of wide arithmetic.

Calling everything AI-generated is lazy

2026-06-25T00:00:00+02:00

The new lazy comment’s “AI-generated”.

On Hacker News, every thread about a programming language that isn’t Rust eventually gets a Rust comment. It doesn’t matter if the topic’s C, Zig, Go, PHP, Elixir, or a database. Somebody will find a way to turn the discussion into Rust.

We now have the same reflex for writing.

Someone publishes a blog post. Maybe something a shower thought. Maybe just a weird thing they spent the weekend trying to understand.

Instead of pointing to a wrong number, a missing test, a wrong claim, or saying thank you, somebody just writes “sounds AI-generated”.

That isn’t criticism. It gives the author nothing to fix. No sentence. No claim. No result. Just a little accusation dropped in the middle of the room. Just sending bad vibes for no reason.

And it lands on real people.

A lot of personal blogs aren’t content businesses. They’re notes written after work, or on a weekend, or at 4am, while the author’s still excited or annoyed enough to explain what they just found. The research may’ve taken days. The writing may’ve taken hours. The reward’s usually nothing. Maybe one useful comment. Maybe one email years later. Maybe just knowing that the next person won’t lose the same afternoon.

Calling that “AI-generated” isn’t harmless.

The garbage sites that actually publish AI slop don’t care. There’s nobody behind them feeling insulted. The pipeline doesn’t read Hacker News. It doesn’t get discouraged. It doesn’t wonder whether publishing was a mistake. It scrapes, generates, publishes, and repeats.

The person writing a blog does read it.

I’m French. English isn’t my native language.

When I write, I don’t first think “how would a native speaker phrase this?” I think about the thing I just did or the idea I want to get out before the excitement’s gone.

And I use a computer, so yes, I use tools.

I utterly hate AI-generated content. I don’t want machines to replace personal writing with synthetic filler.

But AI as an assistant is different.

Checking. Verifying. Proofreading. Helping me say in English what I already know I want to say. That is useful.

I use Apple Intelligence proofreading on my Mac all the time. I ask ChatGPT to fix my English. It fixes grammar. It removes very French sentence structures. It rewrites everything into something that looks a bit too clean. Do you really think I can’t see it too?

AI-assisted prose has patterns. Any idiot can recognizing its stinky smell.

But a spell checker doesn’t make a post fake. Grammarly didn’t make old posts fake. A machine helping a non-native speaker write more readable English doesn’t make the work fake.

The work’s the part before the sentence.

Did I write from actual experience? Did I put my name on the result and accept being wrong in public? This is what should matter.

That’s also why the drive-by accusation is so annoying.

Real AI slop exists. It’s everywhere and it’s awful. But as a filter, “this sounds like AI” is just fkcing annoying.

Mostly, it detects fluency. That’s exactly what non-native writers use tools for. It punishes people for making their English easier to read. It pushes them toward a stupid choice: write worse and sound human, or write better and become suspicious.

That sucks.

If a post’s wrong, say what’s wrong. If a chart’s bogus, show the bug. If a claim’s too strong, argue with the claim. If a paragraph’s clearly hallucinated, quote it.

But a drive-by “AI-generated” comment’s just a status signal. It says “I noticed the current thing.” It doesn’t improve the discussion. It doesn’t protect anyone. It doesn’t help the author. It only makes publishing feel worse.

And publishing personal writing already has a cost.

You expose how you think. You expose what you don’t know. If you write in a second language, you also expose every awkward sentence. There’s always the small fear that the post’s too rough, too direct, too French, too wrong.

Proofreading tools reduce that friction. They let me share the technical part instead of spending all my energy fighting articles and prepositions.

If that makes some sentences look assisted, so be it.

I care more about whether the content’s useful than whether every comma proves I typed it manually.

The annoying part’s that people keep saying they want the human web back. They want personal blogs, independent notes, small discoveries, weird experiments, people writing outside platforms.

Then the same people make it unpleasant to publish any of that.

Haters are gonna hate. Fine.

But this particular kind of hate costs something. The AI farms survive the comments. Humans may not.

So no, I won’t apologize for using proofreading tools.

If you want to fight AI slop, fight empty work. Fight fake expertise. Fight articles with no author, no experience, no accountability, and no point.

Don’t make humans prove they’re human every time they write a decent sentence.

That’s how you get fewer humans writing.

Performance of WebAssembly runtimes in 2026

2026-06-23T00:00:00+02:00

I wanted to know if WebAssembly runtimes are getting faster.

This is a follow-up to the earlier libsodium WebAssembly benchmarks from 2019, 2021 and 2023.

Not “does the newest version beat native code in one microbenchmark?”, and not “which runtime has the prettiest benchmark chart?”, but something more boring and more useful:

If I take the same C crypto code, compile it to WebAssembly, and run it on the latest runtime, a runtime from one year ago, and a runtime from two years ago, are things actually improving?

So I benchmarked libsodium on WebAssembly runtimes released around June 2024, June 2025, and June 2026.

The short version:

wasmer is the best performer, but WAVM, WAMR and Wasmtime are close.
WAVM has the best optimizer, and is able to generate very fast code out from baseline, portable WebAssembly
The new WebAssembly wide_arithmetic instructions are a big deal for crypto code when runtimes support them.

What I measured

The test program is libsodium’s benchmark suite, built from libsodium commit 8e3be8615ba6adcd7babaecf5e76f516890ba5fb.

I built one native baseline and several WebAssembly variants:

native x86-64, compiled with Zig using the local CPU target
plain WebAssembly
WebAssembly with lime1
WebAssembly with lime1 and simd128
WebAssembly with lime1, simd128, and wide_arithmetic

For the native reference, libsodium was built with -Dcpu=native. For wasm2c, the generated C was compiled with zig cc -O3 -march=native.

For WAMR, I used AOT mode: wamrc compiled each .wasm file to an .aot file, and iwasm ran the resulting AOT file. wamrc doesn’t accept --cpu=native, so I used --target=x86_64 --cpu=x86-64-v4 --opt-level=3, which matches the host’s available x86-64 feature level and works across the WAMR versions that could compile these modules.

The native command was:

zig build -Denable_benchmarks -Doptimize=ReleaseFast -Dcpu=native -Diterations=3

The WebAssembly commands were the same shape, with a wasm32-wasi target and the feature-specific CPU strings:

zig build -Denable_benchmarks -Dtarget=wasm32-wasi -Doptimize=ReleaseFast -Diterations=3
zig build -Denable_benchmarks -Dtarget=wasm32-wasi -Doptimize=ReleaseFast -Dcpu=lime1 -Diterations=3
zig build -Denable_benchmarks -Dtarget=wasm32-wasi -Doptimize=ReleaseFast -Dcpu=lime1+simd128 -Diterations=3
zig build -Denable_benchmarks -Dtarget=wasm32-wasi -Doptimize=ReleaseFast -Dcpu=lime1+simd128+wide_arithmetic -Diterations=3

The host was an AMD Ryzen AI 9 HX 470 with 12 cores and 24 threads. CPU boost was disabled and the maximum CPU frequency was 2 GHz. The OS was Linux 7.1.0-rc7, and Zig was 0.17.0-dev.948+e949341b7.

The numbers below are the geometric mean of per-benchmark slowdowns relative to the native build. Lower is better. A value of 2.0 means “twice as slow as native” on this machine.

I used ITERATIONS=3, so the very small libsodium tests are noisy and quantized. Rows reporting zero time were excluded from the aggregate.

Versions

For every runtime except WAVM, I used the latest stable release available on June 23, 2026, plus a stable release from roughly one year earlier and one from roughly two years earlier.

Runtime	2024	2025	2026
`Bun`	`1.1.16`	`1.2.17`	`1.3.14`
`Node`	`22.3.0`	`24.2.0`	`26.3.1`
`WAMR`	`2.1.0`	`2.3.1`	`2.4.4`
`WABT wasm2c`	`1.0.35`	`1.0.37`	`1.0.41`
`WasmEdge`	`0.14.0`	`0.14.1`	`0.17.0`
`Wasmer`	`4.3.2`	`6.0.1`	`7.1.0`
`Wasmtime`	`22.0.0`	`34.0.0`	`46.0.0`
`WAVM`	`n/a`	`n/a`	`nightly/2026-04-05`
`Wazero`	`1.7.3`	`1.9.0`	`1.12.0`

WAVM is awkward to compare historically. The old available nightly collapsed to a 2022 binary for both the 2024 and 2025 slots, and that binary refused to run on this machine. I only kept the 2026 nightly.

WAMR 2.1.0, the selected 2024 release, installed fine but its AOT compiler failed on these Zig-generated modules with invalid WASM stack data type. I kept the version in the matrix, but didn’t include an aggregate for it.

Baseline WebAssembly

This is the plain WebAssembly build, without lime1, SIMD, or wide arithmetic.

There isn’t one universal trend.

Wasmtime steadily improved: 2.67x native in 2024, 2.54x in 2025, 2.41x in 2026. It got faster every year, and the gains land in the tenths place, above the noise.

Node also improved slowly, from 8.60x native to 7.95x native.

Wazero was basically flat: 4.84x, 4.70x, 4.72x native. No real movement over two years.

WAMR in AOT mode was already fast in 2025 and stayed there in 2026: 1.59x native, then 1.57x native, the same within this benchmark’s noise. I don’t have a complete 2024 WAMR number because WAMR 2.1.0 couldn’t compile these modules.

Wasmer regressed in the 2025 release I tested, then recovered in 2026. The 2026 baseline barely beats 2024.

wasm2c improved modestly in 2026. It remains one of the best options if ahead-of-time translation to native C is acceptable for your deployment model.

Bun is the outlier. Its 2024 and 2025 results were far behind, but the 2026 result is about three times faster than the 2025 result. It’s still slower than Node on this benchmark, but the direction is excellent.

WasmEdge is fast too, but its command-line behavior changed enough to matter. My first 0.17.0 run accidentally used interpreter mode for compiled modules and looked catastrophically slow. Running the compiled modules with --run-mode=aot fixed it: the 2026 baseline was 1.74x native, between the 2024 and 2025 baseline results.

Best supported build by year

The baseline table is useful because it compares the same WebAssembly target everywhere.

But if you’re choosing a runtime for your own deployment, you probably care about the fastest build that runtime can actually run.

So for each runtime and year, I also selected the best complete result among the supported builds: baseline, lime1, lime1+simd128, and lime1+simd128+wide_arithmetic.

Looks similar to the previous graph, except for Wasmtime and Wasmer that really benefit from wide_arithmetic.

Ranked by the best supported build, the complete current-year results are:

CPU feature variants

The WebAssembly feature story is more interesting than the year-to-year runtime story.

For the 2026 releases, these were the aggregate slowdowns:

lime1 and simd128 alone aren’t magic here. Sometimes they help, sometimes they hurt, and sometimes the difference is lost in benchmark noise.

wide_arithmetic is different.

Only Wasmtime and Wasmer could run the full wide_arithmetic build among the complete stable rows I tested. WAMR rejected it with unsupported opcode 0xfc13. But when wide_arithmetic worked, it was the biggest speedup in the whole experiment:

Wasmtime 46.0.0: 2.41x native without it, 1.46x native with it.
Wasmer 7.1.0: 2.08x native without it, 1.33x native with it.

That’s the kind of change I like. A lot of libsodium’s expensive operations are arithmetic-heavy. If the WebAssembly ISA can express that arithmetic directly, the runtime has much less work to rediscover what the C compiler already knew.

Failures

Most runs completed cleanly, but not all of them.

Bun 1.2.17 failed box_easy in the baseline build. Bun 1.1.16 failed pwhash_argon2i in the lime1 and lime1+simd128 builds.

Node 22.3.0 originally failed pwhash_argon2i, pwhash_argon2id, and pwhash_scrypt in the baseline, lime1, and lime1+simd128 builds. The failures weren’t fixed by increasing Node’s JavaScript heap or stack settings. They were fixed by giving the Wasm modules an explicit maximum linear memory. With the baseline build, a 1024-page maximum, or 64 MiB, made pwhash_argon2i, pwhash_argon2id, and pwhash_scrypt complete. But pwhash_scrypt failed with 512 pages and segfaulted again at 1536 pages and above, so this appears to be a V8 memory-mode threshold rather than a simple “more memory is better” setting.

WAMR 2.1.0, the 2024 slot, couldn’t compile even the baseline modules in AOT mode. WAMR 2.3.1 and 2.4.4 compiled and ran the baseline, lime1, and lime1+simd128 builds, but not wide_arithmetic.

Those failures were excluded from the aggregate. So were benchmark rows with a zero reported median.

So, are runtimes getting faster?

Some of them are.

Wasmtime is the cleanest yes: it got faster every year in this benchmark, by a little each time.

Node is also a yes, but the slope is gentle.

Bun is a loud yes between 2025 and 2026. It still has a lot of ground to cover for this workload, but the improvement is too large to ignore.

Wazero is mostly flat.

WAMR is also mostly flat between the versions that worked here, but “flat” at about 1.4x to 1.6x native is a very good place to be.

Wasmer is mixed if you only look at the baseline, but the 2026 release supporting wide_arithmetic changes the practical answer for crypto code. With that feature enabled, it was the fastest complete 2026 result I could compare across a normal current release.

wasm2c remains good. If you can translate WebAssembly to C ahead of time and compile it for the host, it’s hard to beat.

WAVM produced the fastest 2026 baseline number, but I don’t have a fair 2024 or 2025 comparison.

WasmEdge remains excellent once it’s forced into AOT mode. The accidental interpreter-mode run was a good reminder that command-line defaults are part of the benchmark, too.

Takeaways

If you run CPU-heavy cryptography in WebAssembly, runtime choice still matters a lot.

The spread between the fastest complete current result and the slowest current result is large: Wasmer with wide_arithmetic was 1.33x native, while current Bun baseline was 8.77x native.

Feature support matters too. The same runtime can move from “pretty good” to “surprisingly close to native” when the WebAssembly module can use better arithmetic instructions.

The comforting part is that the mainstream runtimes aren’t standing still. Wasmtime improved steadily. Bun made a huge jump. Wasmer gained a feature that matters for real crypto workloads. WasmEdge remained fast once the AOT run mode was explicit.

The less comforting part is that WebAssembly performance still isn’t one thing. It depends on the runtime, the release, the enabled WebAssembly features, whether the code goes through WASI from JavaScript, and whether ahead-of-time native compilation is allowed.

So benchmark your actual workload.

But if your workload looks like libsodium, the answer in 2026 is: WebAssembly can be close to native, wide_arithmetic is worth caring about, and yes, some runtimes really are getting faster.

Faster signatures for WebAssembly

2026-06-17T00:00:00+02:00

I just released ed25519-wasm, a small Rust crate for Ed25519 signatures in WebAssembly. The static library can also be directly linked in applications written in other languages.

It’s backed by lib25519, compiled to WebAssembly using Zig, linked to Rust bindings, and exposes a simple API similar to ed25519-compact:

use ed25519_wasm::{KeyPair, Seed};

let key_pair = KeyPair::from_seed(Seed::generate());
let message = b"hello";
let signature = key_pair.sk.sign(message, None);

key_pair.pk.verify(message, &signature).unwrap();

The benchmark

The benchmark in the ed25519-wasm README was run with Wasmtime 45.0.2, using 128-byte messages.

The table reports the median time per operation and the relative speed compared to ed25519-wasm:

Algorithm / implementation	Sign 128B	Verify 128B	Sign vs ed25519-wasm	Verify vs ed25519-wasm
Ed25519 / `ed25519-wasm`	15.1 us	49.1 us	1.0x	1.0x
Ed25519 / libsodium wasm	21.4 us	53.1 us	1.4x slower	1.1x slower
ECDSA-P256/SHA-256 / RustCrypto `p256`	245 us	277 us	16.2x slower	5.6x slower
ML-DSA-44 / Zig std wasm	135.5 us	23.3 us	8.9x slower	2.1x faster
ML-DSA-44 / RustCrypto `ml-dsa`	706 us	91.7 us	46.6x slower	1.9x slower
RSA-2048 / RustCrypto `rsa`	3.21 ms	171 us	212x slower	3.5x slower
RSA-3072 / RustCrypto `rsa`	10.2 ms	394 us	671x slower	8.0x slower

Ed25519 beats everything hands down.

If you already use libsodium, including from Rust through something like libsodium-rs, that’s a perfectly reasonable option.

But ed25519-wasm is slightly faster: 15.1 microseconds to sign and 49.1 microseconds to verify a 128-byte message on Apple M4.

P-256 isn’t close.

ECDSA-P256/SHA-256 with RustCrypto’s p256 takes 245 microseconds to sign and 277 microseconds to verify. That’s 16.2 times slower for signing and 5.6 times slower for verification.

RSA is much worse.

RSA-2048 signing takes 3.21 milliseconds. RSA-3072 signing takes 10.2 milliseconds.

Compared to ed25519-wasm, that’s 212 times slower and 671 times slower.

Verification is less catastrophic, but still bad: 171 microseconds for RSA-2048 and 394 microseconds for RSA-3072.

RS256 is a huge waste of CPU cycles and money

Even when they are not forced to, people use JWT. Especially RS256.

In JWT’s jargon, RS256 means RSA with SHA-256. It’s common because old systems support it, cloud identity products support it, tutorials use it, and people copy what already works.

But if you’re verifying or signing JWT tokens in WebAssembly, avoid RS256.

For signing, it isn’t even close. RSA-2048 is already 212 times slower than ed25519-wasm. RSA-3072 is 671 times slower.

Even verification, the operation JWT consumers usually care about, is 3.5 times slower with RSA-2048 and 8 times slower with RSA-3072.

If this runs in a browser once, maybe you don’t care.

If this runs at the edge for every request, or in a WebAssembly function where CPU time is literally what you pay for, you should care a lot. It’s a terrible choice.

What about post-quantum signatures?

ML-DSA is interesting.

It’s post-quantum resistant, and in WebAssembly, its performance is close to native since it’s mostly based on scalar arithmetic.

The Zig standard library implementation of ML-DSA-44 compiled to WebAssembly signs in 135.5 microseconds and verifies in 23.3 microseconds in this benchmark.

This is actually faster than Ed25519!

But don’t generalize that to every ML-DSA implementation.

RustCrypto’s ml-dsa implementation is much slower, and signs in 706 microseconds and verifies in 91.7 microseconds. That makes signing 46.6 times slower than ed25519-wasm, and even verification is 1.9 times slower.

But with a fast implementation, ML-DSA is a wise choice for WebAssembly if you can afford the large keys and signatures.

Use Ed25519 or ML-DSA, forget RSA

For most WebAssembly applications that need signatures, Ed25519 should be your go-to algorithm.

It’s got small keys, small signatures, simple APIs, fast signing, fast verification, and mature implementations.

If you already ship libsodium to WebAssembly, keep using it. The WebAssembly build performs well, and libsodium remains a good default crypto toolbox.

But if the only thing you need is Ed25519 signatures from Rust targeting WebAssembly, ed25519-wasm is now the best option I know of.

It’s small. It’s direct. It’s backed by lib25519.

If you pay to run WebAssembly code, use this.