Frank DENIS random thoughts.

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.

Feeding a PRF its own tail

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

A while back, while reviewing code for a customer, I stumbled on a custom RNG. It was used for pretty much everything in the application, including generating supposedly unique identifiers.

A custom RNG is usually a red flag, so I took a closer look.

But before getting into how it works, we need to talk about pseudorandom functions.

On PRFs

A pseudorandom function (PRF) takes a key and some input data, and produces a fixed-size output:

PRF(key, data) -> output

Informally, in a secure PRF, given any number of (data, output) pairs, recovering the key is as hard as a brute-force search.

More importantly, no matter how many distinct (data, output) pairs you have already seen, for a new data input any possible output is equally likely. Seeing an output before doesn’t mean a different input can’t produce it again. Unlike a permutation, the security of the function doesn’t degrade as the number of inputs grows.

A common example is SipHash: it takes a 128-bit key and a variable-length input, and produces a 64- or 128-bit output.

The custom random number generator

The custom RNG worked like this:

SipHash(key, state) -> new_state, output

The key is generated from the kernel RNG when the application starts, and never changes afterwards.

There’s also a special case with a static key, where callers of the public API can set the initial state themselves.

The state is initialized to a different value (the seed) for each thread.

Each call splits the function’s 128-bit output into two 64-bit words: the first half overwrites the state, the second half is handed back to the caller as random bytes.

At first sight, the generator may feel reasonable. A 2⁶⁴ domain is borderline, but for most protocols it might be acceptable in practice. The PRF is indistinguishable from random under its key, the state never sits still, and every output depends on the full secret. What could go wrong?

Quite a lot, as it turns out.

The rho-shaped graph

A pseudorandom function is not a permutation. Two different inputs are perfectly free to map to the same output.

And on average, they do: about 37% of the codomain is never hit at all.

What does that mean for our random number generator?

It means the sequence of states is a walk on a graph where every node has exactly one outgoing edge and an unpredictable number of incoming edges. That walk always has the same shape: a tail of states that are never revisited, leading into a cycle that loops forever. Like the Greek letter ρ.

With a 2⁶⁴ state, on average we fall into a loop after about 2³² steps. That’s very small. It’s entirely practical to generate, store, and index the whole cycle on a laptop, and then, given any output, predict the ones that follow.

Feeding a random function its own output gives you about √N outputs, not N. Every doubling of state size buys you one extra bit of effective period, not two.

Threads end up agreeing with each other

The RNG has another failure mode. All threads share a common key, but each starts from a different seed.

So they start at different nodes of the functional graph. But the graph is fixed, and every node eventually leads into one of a small number of cycles. How small?

A random function on N elements has, on average, about ½ ln N distinct cycles. For N = 2⁶⁴, that’s roughly twenty-two. Just twenty-two attractors, into which the entire 2⁶⁴-element state space drains.

So no matter how carefully you seeded your threads with independent entropy, after each one walks its tail of a few billion steps, it ends up trapped on one of those twenty-two cycles.

From that point on, the threads are no longer producing independent streams. They are producing rotations of one of a handful of fixed sequences.

The long-run behavior of the system collapses onto a tiny shared set of orbits.

For applications where the threads’ streams are supposed to be independent, this is bad. The threads end up generating the same sequences.

Short cycles in PRFs

With a PRF and a 64-bit input, about 2³² is the longest cycle you can hope for, and the variance around it is large. Depending on the seed and the exact function, the period can be far shorter.

For example, directly feeding SipHash with a 64-bit output back as the next state, and with key (0, 1) and seed 0x0000004de9886527 the loop closes after only 16,933,653 steps, more than two hundred times shorter than the 2³² you’d expect on average.

Nothing stops a pseudorandom function from cycling faster still, all the way down to a fixed point: a state that maps to itself, so the generator emits the same value forever. Fortunately, SipHash has only one fixed point: the all-zero state, unreachable for any key. Hard to hit by accident.

Backtracking resistance

If the key and some outputs leak, it’s not only possible to predict every future output. It’s also possible to recompute the previous ones.

No preimage search needed: the cycles are short enough that it’s more efficient to just compute them.

A minimal fix

This random number generator is obviously flawed and must not be used in any security context.

It’s also very inefficient, producing only 64 bits per call.

A minimal fix would be to use per-thread keys and a counter:

SipHash(thread_key, counter) -> output

Incrementing the counter after every produced output builds a sequence that won’t repeat until the counter wraps, at which point you should rekey, and you’ll be safe for about 2⁹⁶ outputs. As a bonus, it’s twice as fast as the original generator: 128 bits per call instead of 64.

That doesn’t buy any backtracking resistance, though. The keys still need frequent updates.

I’m also not convinced SipHash is a good fit here, given the input size. AES would be faster, and fine as long as it’s rekeyed before 2³² outputs. Or, if you can use it, AES-PRF (1, 2) lets you go up to 2⁶⁴ output blocks before rekeying, keeping the generic distinguishing advantage around 2^-128, at no performance cost.

A better fix

It’s generally hard to justify building a custom random number generator. These days, the standard library of your favorite language probably ships efficient functions to safely generate random numbers. Use them.

If you really need to build an RNG, be very careful. Use at least a 128-bit or 256-bit state.

Daniel Bernstein’s post on fast-key-erasure random-number generators remains an excellent reference.

Want something fancier and faster than AES-CTR? Use ButterKnife in counter mode (similar to Skye). It outputs 1024 bits per call, and the first 256 can be used as the next tweak and key. PoC.

Want something based on a public permutation? I like Reverie a lot.

But realistically, you probably don’t need any of that.

What happened next

I reported all of this. Years later, the generator itself was never touched; the only change was a line added to the documentation noting that it “should not be used for cryptographic purposes”.

Sad.