Frank DENIS random thoughts.

aHash is not a PRF

2026-04-26T00:00:00+02:00

aHash is a fast Rust hasher. It is popular, useful, and very explicitly not cryptographic.

That warning is good. But the documentation also says something stronger: “because aHash is keyed, hashes cannot be predicted without knowing the keys”. That is not true.

For a hash table, keyed hashing usually means something much more modest. It means an attacker should not be able to precompute one pile of colliding keys and reuse it against every process on the internet. Per-map randomization is a practical defense against boring collision-flooding attacks.

But “cannot be predicted without knowing the keys” sounds like a keyed random function. It sounds PRF-like. It suggests that even after seeing hashes for inputs I choose, I still cannot predict the hash of a fresh input.

That is a much higher bar, and aHash does not clear it.

The construction is not AES

The usual fast path uses AES instructions. That detail is easy to overread.

Using AES round instructions does not make the whole construction AES, any more than using xor makes a protocol a stream cipher. The surrounding construction still has to absorb inputs safely, separate domains, and finalize with enough mixing for the security claim being made.

aHash state keeps three 128-bit values:

enc
sum
key

The basic block update is roughly:

enc = aesdec(enc, block)
sum = shuffle_and_add(sum, block)

Then finish() combines the state with a small number of AES instructions and returns 64 bits.

This is a good shape for a fast hash-table hasher. It is not AES-CMAC. It is not AES as a block cipher. It is not a standard PRF construction.

And in practice, it leaks simple key-independent relations between outputs.

aHash doesn’t securely hash transcripts

The Rust Hasher trait exposes several ways to feed data:

write(&[u8])
write_u8(...)
write_u64(...)
write_u128(...)

In aHash, the integer methods collapse into the same internal operation:

write_u8(i)   -> write_u64(i as u64)
write_u16(i)  -> write_u64(i as u64)
write_u32(i)  -> write_u64(i as u64)
write_u64(i)  -> write_u128(i as u128)
write_u128(i) -> hash_in(i)

So these are different public transcripts:

write_u8(0xab)
write_u16(0xab)
write_u32(0xab)
write_u64(0xab)
write_u128(0xab)

But they all become:

hash_in(0xab)

For every key, they produce the same final hash. There’s no context separation. Developers may not expect this.

There’s a more surprising one:

write(&[])
write_u128(0)

For non-empty byte strings, aHash adds the input length before absorbing bytes. For the empty string, it writes zero directly. The typed u128 path also hashes zero directly.

So two very different transcripts can produce the same hash, independently from the key.

That being said, the Hasher trait doesn’t really define how inputs are supposed to be handled. Being type-safe for hashing transcripts is an option, concactenating everything is another option, but anything else is technically valid as well, even if it is prone to misuse.

An integral distinguisher

Consider u128 inputs constructed that way:

X[a,b] = (a << 56) | (b << 120)

a and b each range from 0x00 to 0xff.

So these are 128-bit values where byte 7 and byte 15 vary over every possible value, and all other bytes are zero.

Now, consider every query:

h.write_u128(X[a,b])
h.finish()

That gives 65,536 different typed inputs. Their 64-bit outputs have a zero XOR sum for any key.

Again, that is not how a PRF from u128 inputs to 64-bit outputs behaves. For independent random outputs, the XOR should be zero with probability 2^-64. In aHash, it is zero every time.

The reason is that write_u128() feeds the value directly into hash_in(), and these byte positions create a balanced set through the reduced AES-based finalization. The key changes the individual hashes. It does not change the XOR relation.

This also makes the output predictable. Leave out one X[a,b], query the other 65,535 values, XOR their outputs, and the result is the missing output.

Here is a trivial PoC:

use aHash::RandomState;
use std::hash::{BuildHasher, Hasher};

fn hash_u128(state: &RandomState, x: u128) -> u64 {
    let mut h = state.build_hasher();
    h.write_u128(x);
    h.finish()
}

fn main() {
    let state = RandomState::with_seeds(1, 2, 3, 4);
    let mut xor = 0u64;
    for a in 0u8..=255 {
        for b in 0u8..=255 {
            let x = ((a as u128) << 56) | ((b as u128) << 120);
            xor ^= hash_u128(&state, x);
        }
    }
    assert_eq!(xor, 0);
    println!("xor {xor:016x}");
}

This prints:

xor 0000000000000000

Of course, typed u128 inputs are still easy to wave away. Many real keys are strings or byte slices. But they are affected by the same issue.

Transposing the distinguisher to strings

Consider this family of 16-byte strings:

S[a,b] = 00 00 00 00 00 00 00 aa 00 00 00 00 00 00 00 bb

a and b each range from 0x00 to 0xff.

That gives 65,536 different non-empty byte strings. No typed integer writes. No empty input. No repeated input. No weird transcript ambiguity.

For each string, do the ordinary thing:

h.write(&S[a,b])
h.finish()

The XOR of all 65,536 outputs is always zero, for any key.

That should not happen for a real PRF. For 65,536 independent 64-bit outputs, the XOR would be zero with probability 2^-64. Here, it happens every time.

The reason is that the varying bytes are placed as the high bytes of the two 64-bit lanes consumed by the 16-byte byte-slice path. Those positions avoid carry trouble in the lane additions, so the chosen set stays balanced before it reaches the reduced AES-based finalization. The key changes the individual outputs. It does not remove the relation.

This is the same kind of balanced-set behavior behind square/integral attacks on AES-like constructions, showing through a construction that uses too little AES-style mixing to hide it.

Pick a target:

T = S[0x42, 0xa5]

Now hash the other 65,535 strings in the family, but not T. XOR their outputs together.

The result is exactly the missing output:

prediction = xor_{(a,b) != (0x42,0xa5)} aHash_k(S[a,b])
prediction = aHash_k(T)

No key recovery. No brute force. Just a key-independent relation.

Another quick PoC

use aHash::RandomState;
use std::hash::{BuildHasher, Hasher};

fn hash(state: &RandomState, bytes: &[u8]) -> u64 {
    let mut h = state.build_hasher();
    h.write(bytes);
    h.finish()
}

fn main() {
    let state = RandomState::with_seeds(1, 2, 3, 4);
    let target = (0x42, 0xa5);
    let mut prediction = 0u64;
    let mut actual = 0u64;
    let mut s = [0u8; 16];
    for a in 0u8..=255 {
        for b in 0u8..=255 {
            s[7] = a;
            s[15] = b;
            let out = hash(&state, &s);
            if (s[7], s[15]) == target {
                actual = out;
            } else {
                prediction ^= out;
            }
        }
    }
    assert_eq!(prediction, actual);
    println!("predicted {prediction:016x}");
}

This prints:

predicted 2929121e3dfcdd2a

The exact value is not the point. The assertion is. The program never adds the target hash to prediction. It only hashes the other 65,535 strings.

What this proves

This does not prove that aHash is useless.

It does not give a giant collision set. It does not recover the key. It does not immediately produce a practical HashMap denial-of-service attack. It does not mean every application using aHash is broken.

Hash-table hashers are not MACs. They are judged by different criteria: speed, distribution, and enough randomization to make precomputed collision attacks unattractive.

But aHash is not a PRF-like keyed hash over byte strings. Some outputs are algebraically related. One output in this family can be predicted exactly from the others without knowing the key.

That is incompatible with the strong reading of “cannot be predicted without knowing the keys”.

aHash can still be a perfectly reasonable fast hash-table hasher as long as the output remains secret. The crate is also right to say that it is not cryptographically secure.

But do not use it as a MAC. Do not use it as a cryptographic keyed hash. Do not use it as a PRF. Do not use its output as randomness. Be careful with non-cryptographic designs such as sharded routing if an adversary gets to choose inputs and observe outputs.

Swival is the AI agent I actually wanted

2026-04-13T00:00:00+02:00

Swival is a CLI AI agent, and Swival 1.0.0 has just been tagged.

People are going to ask the obvious question.

Why build a new agent when Codex, Claude Code and Opencode already exist, are well established, and already look good enough for most people?

Because I wanted an agent that fixes the things existing agents still get wrong in actual daily use.

Privacy, local models, and not leaking secrets to a provider

Current agents are built around genuinely incredible models.

But I still don’t trust companies such as Anthropics with my data. For open source work, fine. For closed-source work, or anything sensitive or personal, I think the default posture of most current tools just isn’t acceptable.

Using an AI agent inevitably leaks internal information. Sometimes a lot of it.

That includes access tokens, internal project names, URLs, company names, and all the little bits of context that look harmless until they aren’t.

Mitigating that risk is something I have cared about for a long time. I even gave a Zigtoberfest talk about that exact topic.

So I wanted an agent that does two things properly.

First, it needs mitigations for leaking secrets to providers.

That means transparently encrypting secrets before sending them to providers, then decrypting them locally so that models can still reason about them without actually seeing them. And it means being able to block and redact specific strings such as internal project names, company names and URLs.

The fact that current agents, including the ones heavily used by corporations, still don’t ship these features is, to me, irresponsible and unacceptable.

Swival has transparent secret encryption and outbound LLM filters specifically to reduce how much information leaves your machine.

Second, it needs to work well with open source models. Not as a checkbox. Actually well.

Local models have predictable behavior and predictable cost. They don’t suddenly get worse because a provider changed something. They don’t suddenly get more expensive because pricing moved. You control them, not a third party.

And of course, they also don’t leak sensitive data to anyone.

Open source models are getting good fast. Gemma 4, Qwen 3.6, and GLM-5.1 make that pretty obvious. Plenty of exciting models are uploaded to Hugging Face every day.

At the same time, efficient local inference is turning into a basic requirement for modern devices, and it’s only going to improve. Apple M5 chips are a good illustration of where this is going.

No, local models aren’t a replacement for everything. But they’re already good enough for a lot of work, they have a bright future, and they can be fine-tuned.

Even modern small models have surprisingly strong agentic capabilities.

The frustrating part is that most agents are still optimized and tested mainly for frontier models. Even the ones that advertise support for many providers and local models usually behave badly with local models. Tools are used poorly. Context is managed poorly. Everything gets slower. Output quality gets unreliable. Then people blame the model instead of the tool.

I wanted an agent that performs well with any model. From large frontier models all the way down to small local models with a small context window that anyone can run on their own machine.

And if it fails, I want the first instinct to be improving the agent so that it helps the model deliver as much as it can, not immediately declaring the model useless.

That’s one of the main reasons Swival isn’t just for frontier models. A lot of that comes from excellent context management.

Swival has a /compact command. But in practice, it’s rarely needed, if at all. The agent keeps trying to deliver regardless of the constraints, and the context window isn’t something you should have to babysit during a long session.

And when I want to test new models, there’s nothing more convenient than HuggingFace CPU-less inference. So I wanted that to be trivial as well.

With Swival, it’s as easy as:

swival --provider huggingface --model zai-org/GLM-5.1

Agent-to-Agent is too useful to remain niche

The A2A protocol is great.

People who actually use it know how powerful it is, and they usually don’t want to go back to a single isolated agent.

Unfortunately, for most people, A2A is still one of these things they have vaguely heard about but never really use, mostly because mainstream tools such as Claude Code still don’t support it.

That’s a shame, because A2A changes what an agent can be.

With A2A, you can run multiple agents with different configurations and different models, and let tasks naturally reach for the right one.

So instead of stuffing documentation and skills into one local agent, you can have a dedicated documentation agent with direct access to the material, while other agents don’t need to carry all of that context.

Then, when an agent needs to know how to do something, it asks the documentation agent to research it and return a concise, accurate answer instead of dumping blind grep results.

And of course, that specialized documentation agent can run a small, cheap, local model.

That’s the larger idea. Don’t restrict yourself to one model, or even a tiny set of related models. Use as many models as you want, including open source ones, depending on what needs to be done.

I wanted A2A to be simple enough that people would actually use it.

Swival comes with built-in support for A2A and can act both as a server and as a client.

You can set up a network of specialized agents in minutes.

Open source, readable, powerful, and not a circus

Existing agents have become ridiculously bloated over time.

Claude Code is enormous. It flickers. It crashes. New versions keep adding gadgets I don’t care about while making the whole thing even heavier.

I don’t want a kitchen sink. I want a small, reliable tool.

Swival is lean, fully open source, doesn’t depend on any company, and isn’t optimized around a specific provider. It’s totally free and open, and has nothing to sell.

It’s written in Python because Python is simple, readable and maintainable. Nothing is obfuscated. Anyone can read the code, understand it, and modify it for their own needs.

And this isn’t a toy. It’s a workhorse. A boring one, which is exactly what I want here.

It focuses on the tools a developer actually needs, not on gimmicks. But it still has the features you would expect from a modern agent, and then some.

Benchmarking needs a real environment

I also wanted to run benchmarks.

I wanted a tool to evaluate models, settings, skills, MCP servers, and similar pieces on real-world tasks, in an environment that actually resembles how a user works.

A lot of benchmarking tools aren’t designed that way.

They either assume tools optimized for specific models, or they provide an environment that doesn’t feel much like the real thing.

And if you want to learn anything useful from evaluations, you need traces. Detailed ones. Accurate ones.

You need to be able to look at what happened and understand how a model behaved under different conditions.

Swival comes with strong reporting features. Combined with calibra, you can compare traces, diff them, and run evaluations that are actually meaningful.

Evaluating many configurations can burn through a lot of tokens.

That’s yet another reason I cared so much about making the agent work well with open source models running locally. For evaluations, cost is often more important than wall-clock speed.

LLMs fail on the first try

The real problem is that models produce terrible code and then confidently tell you everything is fine.

Watching a model generate code is impressive. It’s hard not to be impressed when you type a prompt and a feature, or sometimes a whole project, appears in one shot.

And the final report is always soothing. Everything is done. Everything works.

Of course.

The reality is that AI-generated code is almost always poor quality.

It may compile. It may appear to work. But from a correctness perspective, it’s often terrible.

You may be very happy with the code generated by Claude Code with Opus 4.6 max pro high thinking max, and maybe even want to deploy it to production, merge it into open source projects, or write triumphant blog posts about it.

But there’s a good chance that the code is inefficient, buggy, hard to maintain, and going to cost you later.

There’s a trivial experiment anyone can try.

Ask your favorite agent to generate code, or even just a plan.

Then, in a separate environment, ask another AI agent, even one running the same model, to review that code or plan.

It’s very likely to find issues immediately. Sometimes critical ones.

As much as I like AI, in my own projects I refuse pull requests blindly generated by tools such as Claude Code for exactly that reason. And in a company context, I wouldn’t deploy that output to production either.

There are two ways to significantly improve quality and confidence.

First, write the tests first, then force the agent not to declare the task complete until the tests pass.

The tests don’t even have to be part of the application’s formal test suite. A simple shell script with curl commands can be enough.

What matters is that this becomes a contract the agent has to satisfy.

That’s much stricter than a prompt, because a contract can’t be hand-waved away or interpreted creatively.

Second, use a loop with an LLM-as-a-judge.

Let one agent write code, documentation or a plan. Then let another agent review that work against the original instructions, and force the implementer to retry until the reviewer thinks it’s correct.

Swival makes both of these approaches trivial because they’re built in.

Before starting a task, you can give the agent a script that will act as a reviewer.

That reviewer can be another swival instance with a custom configuration. Or, even more simply, you can start with --self-review, and tasks will be reviewed by the same instance and same model in a dedicated context.

There’s nothing else to wire together.

One of the most interesting things to watch is how bad the initial output of an LLM agent can be, especially for code, and how honest and picky a model can suddenly become when it’s reviewing its own output without realizing it.

After a couple of iterations, the code, plan or documentation is often far better than the first attempt.

This is also one of the main reasons I wrote a new agent at all.

I don’t want to use AI to generate a mountain of code just so I can brag about productivity if the result is unreliable, insecure and unmaintainable.

I wanted an agent that optimizes for quality rather than raw time savings.

It can be slow. It can be expensive. But I want the output to be something I can trust and deploy to production.

Long sessions shouldn’t make the agent dumber

Another thing I wanted was continuity.

I wanted an agent that remembers what I did before, and what it did before.

When I come back to the same project the next day, I want the agent to remember prior work without filling the live context with junk.

Swival does that in a way that feels much more natural than in other agents.

I also wanted it to stop making the same mistakes twice.

So Swival has a /learn command: at the end of a session, the agent can reflect on the issues it ran into and write concise instructions about how to avoid repeating them. And once those learnings exist, it will keep updating them automatically.

That has turned out to be much more effective than premade agent skills. Or, more accurately, it’s an extremely effective way to produce the right skills, because the agent discovers what it actually needs from real sessions instead of from speculation.

Goals

One of the most frustrating things about working with an agent on a non-trivial task is how often it declares victory too early.

It runs for a few turns, fixes something, and then politely tells you it’s done. Except it’s not. There are still failing tests, missing pieces, or edge cases it quietly decided weren’t worth its time.

You re-prompt. It does a bit more work. It tells you it’s done again. And so on, until you give up and finish the task yourself.

People have been working around this with the so-called Ralph-style loop, which essentially means feeding the same prompt back to the agent in a shell loop until it stops finding things to do. It works, but it’s clumsy and wasteful.

I wanted something more structured, built directly into the agent.

In Swival, you set an objective with /goal <objective> in the REPL, and the agent stays on task across turns. The original objective is fed back to the model after every answer, and the loop only ends when the agent itself signals that the goal is complete after a real evidence-based audit, declares a blocker that needs your input, or hits an optional token budget.

The agent doesn’t get to walk away after one turn just because it feels good about its work.

This makes it practical to point Swival at ambitious long-running tasks such as refactors, audits or end-to-end fixes, and let it grind for hours without giving up halfway. You can pause, resume, replace, or clear the goal at any time.

It’s a small feature on paper, but in practice it changes what you can reasonably ask an agent to do.

Modern features, but without the usual mess

Skills, MCP, parallel subagents and similar capabilities are table stakes for serious agent use now. Of course Swival supports all of that.

But I also wanted it to avoid the usual security and reliability mistakes.

So tool and MCP output are explicitly tagged as untrusted in order to reduce prompt-injection risk.

And markdown comments are ignored, so what you see in a rendered skill isn’t different from what the agent actually interprets.

There’s another common failure mode I have always found silly.

If an MCP command or tool returns a large output, many agents either stuff the whole thing into the context window or fail in some awkward way.

I wanted an agent that handles that properly. Swival writes large outputs to a temporary file and lets the agent access them in chunks later instead.

I also wanted a clean way to share files such as agent memories and AGENTS.md across multiple devices working on the same project, without committing them into a Git repository.

Swival has lifecycle hooks specifically for that sort of workflow.

Arbitrary commands are easy too. In ~/.config/swival/commands/, you can place either scripts or plain files. Then ! command_name will inject either the content of the file or the output of the script into the prompt.

Yes, other agents have versions of this. But I wanted it to be trivial from a user perspective.

Not five overlapping systems with five different names for basically the same thing. Just one simple mechanism.

The same goes for shell command inspection and rewriting.

I didn’t want people to need to learn some complicated generic hook system.

In Swival, enabling command middleware is safe and straightforward.

And more importantly, I wanted the agent to be usable programmatically, not just from the CLI.

I also didn’t want that to require a separate SDK with its own worldview and its own behavior. Everything the CLI agent does should be accessible in a consistent way from Python code.

This is why Swival can be used as a CLI, but also as a library. It exposes a very simple API so anyone can build custom agents, or more general applications, on top of a batteries-included agentic environment.

Small things matter

Some of the things I cared about aren’t glamorous.

They’re just the kind of rough edges that make a daily tool annoying.

For example, markdown rendering for LLM output looks nice, but I dislike the fact that copy-pasting rendered output often strips the markdown markers.

I also don’t love the idea of an agent accidentally deleting files.

These are small things. But they matter if you actually use the tool every day.

Swival renders LLM markdown output while preserving the formatting tags.

So the output looks good, but can still be copied and pasted without losing the markdown.

And even in full YOLO mode, it has safety guards against dangerous commands, plus built-in support for the AgentFS copy-on-write filesystem overlay.

Also, when a file is deleted using Swival’s own tools, it isn’t actually deleted. It’s moved to a Trash directory instead.

I have never personally seen an agent delete the wrong file. But if it ever does happen, I want recovery to be possible.

Why I use it

At this point, I use Swival almost exclusively. It’s reliable, and I’m happy with the output I get from it.

I use open source models as much as possible, both locally and via HuggingFace inference endpoints.

But when I need a frontier model, I use it with GPT-5.5. This is a fantastic model. It works amazingly well with a regular ChatGPT subscription, and I have never hit any usage limit.

If you are happy with your current agent, there are no reasons to switch.

But I would still strongly encourage you to try Swival. Maybe even use it alongside the agent you already use.

Because even with the very same models, it’s likely to find bugs your other agent never found. That isn’t magic: different agents expose different environments to models, and models behave differently in those environments.

I have used the /audit built-in command and it found bugs and vulnerabilities in pretty much every code base I tried it on, including code bases that had already been audited with Codex and Claude Code.

That’s the kind of difference I care about. Whether the tool helps me find real problems and ship better work.

So yes, give it a try.

What’s next

Version 1.0.0 doesn’t mean Swival is done.

It means it now checks all the boxes from my original todo list, and it’s stable enough for daily use.

The API is also unlikely to see major breaking changes, so it’s something you can reasonably rely on if you want to build applications and agents on top of it.

There are still many planned changes and features. But Swival will remain driven by real-world usage and user feedback, not by a roadmap for the sake of having a roadmap.

Related projects are going to keep expanding as well.

Right now, they’re:

Calibra, to evaluate models, MCP servers, skills, and related configurations
Skillscheck, a linter for agent SKILL.md files
Agent Skill Lint, a Visual Studio extension for agent skills linting
Swival commands, a repository for user-contributed commands

Swival exists because I wanted an agent that takes privacy seriously, works with the models I actually want to run, gets better over long sessions, and pushes code quality up instead of pretending quality doesn’t matter.

Most agents still optimize for marketing. I wanted one that optimizes for the work.

That’s Swival.

Configuration flags are where software goes to rot

2026-04-11T00:00:00+02:00

People love configurable software.

They say flexibility is always good. More flags, more knobs, more environment variables, more ways to make the software fit every possible use case.

But in practice, configuration flags are often just a polite way to ship uncertainty.

A feature is added, but no one is completely sure it should be enabled by default. So, it gets a flag.

A behavior is changed, but backward compatibility is scary. So, it gets a flag.

Two users want opposite things. So, both paths stay in the code forever, behind a flag. At first sight, this looks reasonable.

Of course, a flag can be useful. Experimental features need a way to be tested. Migrations sometimes need a temporary escape hatch. And some software is genuinely used in environments that are different enough to justify a couple switches.

But temporary flags are rarely temporary. Once a flag exists, it starts attracting dependencies.

Documentation has to mention it. Support has to ask whether it is enabled. Bug reports have to include it. Tests need to cover both states. New features have to decide which side they are compatible with. And if the flag affects a file format, a protocol, or anything persisted, removing it later becomes painful. That is the real cost.

The code behind a flag is not one feature. It is two possible worlds that the maintainers now have to keep alive.

This gets worse when flags are not independent. One flag changes timeouts. Another one changes buffering. Another one changes concurrency. Individually, each sounds harmless. Together, they create a configuration space no one has actually tested.

Users then report that “it doesn’t work” on a setup that technically should be supported, but only with FAST_MODE=0, LEGACY_IO=1, the old parser, and a kernel old enough to vote.

Nobody designed that combination. It just happened. And now it is your problem.

A lot of software teams treat flags as free because adding a boolean looks cheap. It isn’t.

A boolean in the interface usually means a branching factor in maintenance.

This is especially obvious in open source. If a user asks for a niche feature, adding a flag feels like a compromise. The maintainer doesn’t have to bless the behavior as the new normal, and the user gets what they want.

But what actually happened is that the maintainer accepted long-term responsibility for behavior they may never use themselves.

The contributor will disappear. The flag will stay.

And five years later, some poor soul will ask why --compat-relaxed-fsync cannot be combined with the new backend on FreeBSD. Because software has memory.

The scary part is that flags often hide design problems.

If users regularly need a flag to disable a subsystem, maybe that subsystem is too eager.

If performance requires half a dozen tuning variables, maybe the defaults are bad or the architecture is brittle.

If a migration needs three generations of compatibility toggles, maybe the old behavior was never clearly isolated from the new one.

Flags can solve real problems. But they can also keep bad design alive by preventing the moment when someone has to say: this behavior was wrong, and it has to go.

Sure, removing options can upset people. But keeping everything forever quietly upsets the maintainers instead.

That cost is less visible, because it shows up as hesitation, slower releases, defensive coding, weird bugs, and documentation that reads like legal terms.

So, should software have no flags at all? Obviously not.

But flags should have the same status as debt: sometimes necessary, never free, and always suspicious.

Every new flag should come with an expiration story.

Why does it exist? Who needs it? What breaks if it goes away? When will that be acceptable? If nobody can answer these questions, the flag is probably not a feature.

It’s a fossil in progress.

Fast sorting, branchless by design

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

Sorting is one of the most studied problems in computer science. Every language ships a built-in sort, and for most applications, picking the right one is a matter of performance. Quicksort, mergesort, pdqsort. They all produce the correct output. The main question is how fast they get there.

But there’s a class of applications where correctness and speed aren’t enough. When the data being sorted is sensitive, the sort itself can become a security vulnerability. Not because it produces the wrong result, but because an attacker who observes execution time can learn something about the data.

This is not theoretical. Post-quantum cryptosystems like Classic McEliece and NTRU Prime use sorting as a core subroutine, and if the sort leaks timing information, the entire cryptosystem is compromised.

There is, however, a family of algorithms that eliminates this problem entirely, and when implemented well, can even outperform traditional sorts.

Why sorting leaks information

Consider quicksort.

It picks a pivot, partitions the array around it, and recurses. Which pivot gets chosen, how the partitioning plays out, and how deep the recursion goes all depend on the values in the array. Different inputs produce different branch patterns, different memory access sequences, and different execution times.

An attacker who can measure execution time, even remotely over a network, can use those timing differences to deduce information about what’s being sorted. This is a timing side-channel attack.

The problem isn’t specific to quicksort. Any sort whose control flow depends on the data is vulnerable. Mergesort’s merge step branches on comparisons. Insertion sort’s inner loop length depends on how far each element needs to move. Even pdqsort, which combines several strategies, makes data-dependent decisions at every level.

What we need is a sort where the sequence of operations is completely fixed: determined only by the array length, never by the values. The same comparisons, the same memory accesses, the same number of instructions, regardless of whether the array contains [1, 2, 3] or [3, 1, 2].

Sorting networks

A sorting network does exactly this. It’s a fixed circuit of compare-and-swap operations wired together in a specific pattern. Each comparator takes two values and outputs them in order: the smaller one goes to one wire, the larger one to the other. The entire network is determined at construction time, before any data is seen.

The simplest sorting network sorts two elements. It’s a single comparator: take two values, output (min, max). Done. For three elements, you need three comparators. For four, you need five. The pattern grows, but the key property remains: the comparisons don’t depend on the data. The same wires get compared in the same order every time.

This is what makes sorting networks attractive for cryptography. The comparison pattern is data-oblivious: an attacker watching the execution sees the exact same sequence of operations regardless of what’s being sorted.

Bubble sort as a sorting network

It turns out that bubble sort, often dismissed as the worst sorting algorithm, is already a sorting network.

Think about what bubble sort actually does. On each pass, it compares adjacent pairs from left to right: elements 0 and 1, then 1 and 2, then 2 and 3, and so on. If a pair is out of order, it swaps them. After n-1 passes over an array of n elements, the array is sorted.

The comparison pattern is always the same. It doesn’t matter what values are in the array: bubble sort always compares the same pairs in the same order. It’s a fixed schedule of compare-and-swap operations. That’s exactly the definition of a sorting network.

The problem is efficiency. Bubble sort needs O(n) passes, each with O(n) comparisons, for a total of O(n²) comparators. For tiny arrays that fit in L1/L2 caches, bubble sort can be surprisingly fine in practice. But for large arrays, it’s far too slow.

Odd-even transposition sort

A natural improvement is to parallelize. In odd-even transposition sort, instead of sweeping left-to-right, you alternate between two phases:

Phase A: compare and swap pairs (0,1), (2,3), (4,5), ...
Phase B: compare and swap pairs (1,2), (3,4), (5,6), ...

Within each phase, all the comparisons are independent: they operate on disjoint pairs of elements, so they can all happen simultaneously. And after n phases, the array is sorted.

On a single processor, this is no faster than bubble sort. But it demonstrates something important about sorting networks: they expose parallelism. All comparisons within a phase are independent, which is a property that data-dependent sorts like quicksort fundamentally cannot offer, because each comparison depends on the results of previous ones.

Still, odd-even transposition sort has O(n) depth (sequential phases) and O(n²) total comparators. We can do much better.

Bitonic sequences

The key insight that leads to efficient sorting networks comes from a special kind of sequence: a bitonic sequence.

A bitonic sequence is one that first increases and then decreases like [1, 4, 7, 5, 2]. It can also be a cyclic rotation of such a sequence, so [5, 2, 1, 4, 7] is also bitonic (it falls, then rises, which is the same shape rotated).

Why do we care? Because a bitonic sequence of length n can be sorted by a fixed network with only O(log n) depth.

The trick is called a bitonic merger, and it works like this: compare each element in the first half with the corresponding element in the second half (elements at distance n/2). This single layer of comparators splits the bitonic sequence into two smaller bitonic sequences, one in each half. Recurse on each half, halving the distance each time. After log n layers, the sequence is sorted.

A bitonic merger is a small, efficient, fixed-structure circuit. It is the building block for sorting any array, not just bitonic ones.

Batcher’s bitonic sort

In 1968, Ken Batcher showed how to use the bitonic merger to build a full sorting network. The construction is recursive:

Split the array in half.
Recursively sort the first half in ascending order and the second half in descending order.
The result is a bitonic sequence. Merge it with the bitonic merger.

For clarity, assume n is a power of two. Practical implementations handle arbitrary lengths with padding or tailored networks.

Here’s a concrete example with 8 elements. Start with:

[6, 3, 7, 1, 5, 2, 8, 4]

After recursively sorting the first half ascending and the second half descending (which itself applies the same construction on smaller subarrays), we get:

[1, 3, 6, 7,  8, 5, 4, 2]
 ascending    descending

This is a bitonic sequence: it rises then falls. Now we apply the bitonic merger. The rule is simple: for each pair (i, i+d), keep the minimum at position i and the maximum at position i+d. Halve d after each layer:

    positions: [0, 1, 2, 3, 4, 5, 6, 7]

        input: [1, 3, 6, 7, 8, 5, 4, 2]

d = 4   pairs: (0,4), (1,5), (2,6), (3,7)
          out: [1, 3, 4, 2, 8, 5, 6, 7]

d = 2   pairs: (0,2), (1,3), (4,6), (5,7)
          out: [1, 2, 4, 3, 6, 5, 8, 7]

d = 1   pairs: (0,1), (2,3), (4,5), (6,7)
          out: [1, 2, 3, 4, 5, 6, 7, 8]

Three layers, four comparisons each, and the array is sorted. The comparison schedule was the same regardless of what values were in the array: only the array length determined which pairs got compared.

How many comparisons does this take? Each level of recursion halves the array, so there are O(log n) levels. At each level, the mergers collectively cover all n elements across O(log n) layers. That’s O(n log n) comparisons per level, and O(log n) levels, for a total of O(n log²n) comparators.

This is more work than quicksort’s O(n log n). But the comparison pattern is completely fixed, which is exactly the property we need for constant-time sorting. And O(n log²n) is close enough to O(n log n) to be practical. The extra log factor is a modest price for side-channel resistance. More importantly, layers are made of nothing but simple, disjoint operations that can run in parallel.

This structure is also a natural fit for GPUs. GPUs execute threads in lockstep groups, and when threads within a group take different branches, performance collapses. Data-dependent sorts like quicksort suffer from this. Sorting networks avoid it entirely: every thread executes the same compare-and-swap regardless of the data. Bitonic sort has been one of the standard GPU sorting algorithms for this reason, and is included in NVIDIA’s CUDA samples as a textbook example.

Note that there exists a theoretically optimal O(n log n) sorting network, the AKS network, but its constants are so enormous that it’s unusable in practice. As Knuth put it, Batcher’s method is better unless n exceeds the total memory capacity of all computers on earth.

Vectorizing sorting networks

Vectorized merge-exchange sorting networks have been around since the 1980s. The idea is natural: since all comparisons within a layer operate on disjoint pairs, the CPU can exploit this independence in two ways: SIMD instructions process multiple pairs per instruction, and out-of-order execution overlaps independent scalar operations. The sorting network’s structure exposes both forms of parallelism naturally.

Daniel J. Bernstein’s sorting library takes this further, squeezing more speed out of these networks on current CPUs and adding formal verification tooling that operates on the compiled binary.

In a vectorized Batcher network, the wire ordering is rearranged to be SIMD-friendly.

The core primitive is still the compare-and-swap, but there are two ways to implement it.

The fast path uses hardware min/max instructions. On modern CPUs, packed SIMD min and max operate on entire vectors of elements at once and are inherently branchless. One instruction compares 4, 8, or 16 pairs simultaneously with no data-dependent control flow.

The fallback path uses pure arithmetic. It subtracts the two values to get a difference, extracts the sign bit via a right shift, negates it to produce either an all-ones or all-zeros mask, then XOR-swaps the values conditioned on that mask. Unless the compiler is able to understand and optimize that pattern, we’ll get no branches, no data-dependent memory accesses, and only operations that are expected to run in constant time on the target architecture. The same operations execute regardless of whether the pair was already in order.

A Zig implementation

I ported djbsort to Zig. The library exposes two functions.

sort is the fast path for native numeric types: integers and floats of any width:

const ctsort = @import("ctsort");

var data = [_]i32{ 42, -7, 13, 0, -99 };
ctsort.sort(i32, .asc, &data);
// data is now { -99, -7, 0, 13, 42 }

sortWith handles arbitrary types, including structs. It follows the same interface as std.sort.pdq. You provide a comparison function and an optional context:

const Point = struct { x: i32, y: i32 };

var points = [_]Point{ .{ .x = 3, .y = 1 }, .{ .x = 1, .y = 2 } };
ctsort.sortWith(Point, &points, {}, struct {
    fn lessThan(_: void, a: Point, b: Point) bool {
        return a.x < b.x;
    }
}.lessThan);

Both functions use the same Batcher sorting network topology. They differ in how the compare-and-swap is implemented.

The native path has two levels of optimization. On modern CPUs with SIMD support, it processes elements in vector-wide chunks using packed min/max. For the leftover elements that don’t fill a full vector, it falls back to a scalar compare-and-swap.

The scalar path is gated by a comptime flag called has_ct_minmax. When side-channel mitigations are disabled (side_channels_mitigations == .none), it’s always true. In that specific case, we don’t need constant-time code, so @min/@max are fine on any architecture. But when mitigations are enabled (and by default, they are), it’s only true on x86/x86_64 and aarch64, where @min and @max have been verified to lower to branchless instructions (cmov, csel). On other architectures, the code falls back to the arithmetic sign-bit extraction and XOR swap:

const diff = if (order == .asc) b_int - a_int else a_int - b_int;
const sign_bit: u1 = @truncate(@as(UWInt, @bitCast(diff)) >> @intCast(bits));
var mask_word = @as(usize, 0) -% @as(usize, sign_bit);

The subtraction produces a negative result when the pair is out of order. The sign bit is extracted via a right shift, then spread to a full-width mask via 0 -% sign_bit (wrapping subtraction: 0 minus 1 wraps to all-ones, 0 minus 0 stays zero). The mask drives an XOR swap of the raw bytes.

The generic path (sortWith) behaves differently depending on std.options.side_channels_mitigations. When mitigations are disabled, it uses a plain conditional swap: a branch and std.mem.swap. Fast, but not necessarily constant-time. When mitigations are enabled, it uses ctCondSwap, which XOR-masks the raw byte representation in machine-word-sized chunks. Even with mitigations enabled, sortWith is only timing-safe if the caller-supplied comparison function is itself constant-time. A data-dependent lessThan would leak through the comparator, not the swap.

Both paths use the same optimization barrier to prevent the compiler from undoing the constant-time code:

mask_word = asm volatile (""
    : [mask] "=r" (-> usize),
    : [_] "0" (mask_word),
);

This is a no-op at the hardware level. It generates no instructions. But it tells the compiler that mask_word might have been modified, which prevents LLVM from reasoning about its value and converting the branchless XOR swap back into a conditional branch. This is more efficient than std.mem.doNotOptimizeAway(&mask) which includes a memory clobber.

Float ordering

IEEE 754 floats don’t have a total order. NaN is unordered. It’s not less than, equal to, or greater than anything, including itself. And -0.0 compares equal to +0.0, even though they have different bit representations.

For a sorting network, we need a total order. The sort function imposes one: -NaN < -inf < ... < -0.0 < +0.0 < ... < +inf < +NaN.

The solution is djbsort’s “useint” technique: don’t sort the floats at all. Instead, reinterpret their bits as signed integers, apply a transform that makes integer comparison match the desired float ordering, sort using the integer sorting network, and transform back.

The transform is a function called floatSortKey. Positive floats already sort correctly as integers: larger floats have larger bit values. Negative floats sort in the wrong direction: -1.0 has a larger bit pattern than -2.0, but should come after it. The fix is to arithmetic-right-shift the sign bit to fill the entire word (all-ones for negative, all-zeros for positive), AND with maxInt to clear the sign bit, and XOR. This flips the magnitude bits of negative values, reversing their order while leaving positive values unchanged:

fn floatSortKey(comptime SInt: type, s: SInt) SInt {
    const mask = s >> (@bitSizeOf(SInt) - 1);
    return s ^ (mask & std.math.maxInt(SInt));
}

The transform is self-inverse: applying it twice gives back the original value. So the whole float sort is just a thin wrapper around the integer sort:

if (@typeInfo(T) == .float) {
    const SInt = std.meta.Int(.signed, @bitSizeOf(T));
    const int_items: [*]SInt = @ptrCast(items.ptr);
    const int_slice = int_items[0..n];
    applyFloatSortKey(SInt, int_slice);  // O(n) transform, vectorized
    sort(SInt, order, int_slice);        // reuse the integer sort
    applyFloatSortKey(SInt, int_slice);  // O(n) reverse (self-inverse)
    return;
}

The pre/post transform is itself vectorized, processing elements in SIMD-width chunks. The cost is two linear passes over the array, negligible next to the O(n log²n) sorting work. In benchmarks, float sorting runs within a few percent of integer sorting speed.

Sorting networks trade a modest increase in total work, O(n log²n) instead of O(n log n), for a property that mainstream sorts like quicksort and pdqsort cannot offer: a fixed, data-independent comparison schedule. SIMD vectorization and the instruction-level parallelism inherent in sorting networks make this practical.

On Apple Silicon, the SIMD path (sort) runs 2x to 5x faster than the standard library’s pdqsort across all types and sizes tested, from 16 to 1M elements. For i32 at 1M elements, the vectorized sorting network is still about 3x faster.

On AMD Zen4, the speedups are even larger at small and medium sizes, up to 5.5x at 16K elements. At 1M elements the O(n log²n) work catches up, but the sorting network still wins by about 1.3x.

Floats sort at the same speed as their integer counterparts on both architectures, within a few percent. The generic path (sortWith), which cannot use SIMD, beats pdq up to around 65K elements, then gradually loses as the extra log factor dominates.

For a data-oblivious sort, being faster than a mainstream data-dependent sort across most practical sizes is a welcome bonus. And for the cryptographic use cases that motivate constant-time sorting, arrays tend to be well within that range.

The code is on GitHub.

Don't pass on small block ciphers

2026-02-10T00:00:00+01:00

Although they are omnipresent in constrained environments and lightweight protocols, small (32-bit, 64-bit) block ciphers have a bad reputation. They are perceived as something antiquated, insecure, and to stay away from for any new application, especially in software implementations.

To some extent, thinking that way is safe, and as a general building block, larger block ciphers are more versatile and provide improved security and usage limits than small block ciphers. In fact, due to modern applications and protocols, the trend in some contexts is to realize that 128 bits are not enough, and shift to large block ciphers such as Rijndael-256 and Vistrutah (NIST submission), part of NIST’s wide-block standardization effort, or public permutations such as Keccak.

The main problem with small block ciphers is that well… they are small. Generally, we want the set of possible inputs and outputs to be large enough that it’s practically impossible to enumerate. If that set is small, that doesn’t hold true. Generally, we also want the output of a cipher to be indistinguishable from random for an adversary. But with a 32-bit block cipher, collisions become likely around 2¹⁶ blocks for a given key, and the distinguishing advantage only grows from there, which is ridiculously low. Using them securely is possible, but requires very careful design of application-specific protocols.

Nonetheless, small block ciphers can remain very useful, even in modern applications because in spite of their limitations, they remain block ciphers.

Block ciphers

A block cipher is a fundamental building block in symmetric cryptography.

Imagine a list of N elements. Then, you put them all in a bag, shake the bag really well, and randomly grab all the elements one by one, to form a new list. There are still N elements, just in a completely different order. The first one may now be the 23948234th one, etc. We just applied a random-looking permutation.

If we know what the permutation is, we can easily invert the process, and map element 23948234 back to the first one.

A block cipher is a set of two functions:

A function P(k, x) -> x' that takes a secret key k, generates a random-looking permutation from it, and returns the image of x under that permutation.
A function P'(k, x') -> x that applies the inverse permutation and recovers x from P(k, x).

Without the secret key k, the permutation cannot be recovered, so given x', guessing what x is requires brute-forcing the key space or, for small block sizes, exhausting the (limited) set of possible inputs, as discussed below.

Counters and other small inputs

A common way to use block ciphers is to encrypt a counter. With a 32-bit block cipher, you can safely encrypt a counter from 0 to 2³² without getting a collision, as long as the counter doesn’t wrap around and the same key isn’t reused for a different counter domain. This is still counting, just in a shuffled order.

And in real-world applications, counters are everywhere: packet/frame indices, account identifiers, message numbers, version numbers, and anything using a monotonically incrementing key in a database.

The value of some of these counters may reveal sensitive information. Creating accounts on a website and observing changes in account identifiers is a pretty reliable way to guess how many customers the company has, and if that number is increasing or decreasing. Quite sensitive data for a public company. Similarly, opening support tickets and observing the ticket number leaks information about the company’s business.

A common mitigation is to replace counters with UUID or random identifiers, even in environments providing strong consistency guarantees.

That works, with large enough identifiers.

With UUIDv4’s 122 random bits, generating ~2⁴⁸ identifiers gives a collision probability around 2^-27, which is small but not negligible at scale.

But with a 64-bit block cipher and a counter, up to 2⁶⁴ identifiers can be safely generated with a collision probability of exactly 0.

If more than 2³² identifiers are not necessary for your application, a 32-bit block cipher will do the same job, and keep storage requirements down to a minimum.

Keep using a regular counter, encrypt it with a block cipher before making it public, and decrypt that later if needed to recover the original counter value.

No trusted source of randomness is necessary, and no accurate clock is necessary. The encrypted values themselves won’t be ordered, but you can keep the original counter for internal indexing and only expose the encrypted form publicly.

UUIDs and small block ciphers

What about UUIDs?

UUIDv1 allows adversaries to recover the exact creation time (down to 100 ns resolution), the clock sequence behavior, and a unique identifier of the machine that generated it. The timestamp alone is enough to leak traffic patterns, record creation rates, and sometimes even enable correlation across systems. It’s also predictable. Because UUIDv1 is basically “timestamp + sequence,” once an attacker sees a few UUIDs, they can often predict nearby values. That makes UUIDv1 completely unsuitable as public identifiers and in anything used in URLs or APIs where guessing matters.

UUIDv4 is 122 random bits (the remaining 6 are fixed version and variant markers).

UUIDv6 is “ordered UUIDv1,” mostly for legacy. RFC 9562 basically says: v6 exists to improve DB locality for environments already using v1, but if you’re not tied to v1, you should use v7 instead.

So what about UUIDv7? It’s explicitly time-ordered using a Unix-epoch millisecond timestamp, with the remaining bits used for randomness and/or a counter to keep monotonicity within the same millisecond.

This gives you much better insertion locality than UUIDv4 in many B-tree-style indexes. However, this requires properly synchronized clocks, and v7 leaks creation time. RFC 9562 calls out that timestamps create a (small) attack surface, and if UUIDs are used for security-sensitive purposes, it recommends UUIDv4 instead.

So, you can use UUIDv7 as the database primary key, but don’t treat it as secret.

Meanwhile, the output of a block cipher hides the underlying value, while being much smaller than a UUID, which definitely matters at scale in databases. Being deterministic, it still leaks equality (same input produces same output), distinctness, and frequency patterns, but the actual values remain hidden.

Small block ciphers work well with counters, but they work equally well with anything else that fits within the block size.

And timestamps are no exception: if they represent sensitive information, a small block cipher is a simple, efficient, usually format-preserving way to encrypt and decrypt them.

If you need UUIDs, why not combine them with a small block cipher, so that the timestamp is not leaked, while the UUIDs’ properties are retained?

UUIDv7 is essentially a 48-bit timestamp followed by randomness plus version/variant bits, and optionally a counter to ensure monotonicity within the same millisecond.

Concatenate a 48-bit timestamp with either a 16-bit counter or randomness, and 64 bits of extra randomness to form your UUIDs.

Then, encrypt the first 64 bits with a 64-bit block cipher before exposing them publicly.

The encrypted portion won’t be lexically ordered, but the original UUIDv7 can still serve as the internal primary key for indexing. Expose only the UUID with the encrypted prefix publicly, and decrypt when you need the original back.

Downsides

So far, small block ciphers sound pretty useful. But they do come with real limitations that you need to understand before reaching for one.

The obvious downside of a block cipher is that, for a given key, after having observed M distinct outputs (encryption of M distinct inputs), we know that if we encrypt inputs that we didn’t see before, their encryption will not be part of the outputs we already observed.

So, for a set of N possible outputs, after having observed M distinct outputs, when a new input is encrypted, the probability to guess its encryption is 1/(N-M) per attempt.

This is where small block ciphers come short. If an adversary’s goal is to decrypt a ciphertext, and they have an oracle telling them if a guess is right, depending on the protocol, they may be able to do it.

Small block ciphers are thus generally a bad idea against active adversaries.

However, they can be very useful against passive adversaries whose capability is limited to observing identifiers, who are then unable to map them to the original value.

Usage of small block ciphers is also not incompatible with traditional mechanisms for tamper detection such as MACs.

Another downside is that, for any cipher, the secret key must remain secure. With random identifiers, only the random number generator needs to be secure.

So, what small block ciphers should I use?

There are plenty of small block ciphers designed for hardware, that don’t perform as well in software.

In software on general-purpose CPUs, and as scary as it may sound, the best options were designed by the NSA: the SIMON and SPECK Families of Lightweight Block Ciphers.

While their design is not radically different from well-known, well-trusted ciphers, there was originally a lot of pushback due to their origin.

And, as a side effect, they got a ton of 3rd-party analysis. Due to their simplicity, they are also the first targets of new tools and techniques for cryptanalysis. However, after more than 13 years of 3rd-party analysis, there are still zero practical attacks against them, and they still have a decent security margin. New cryptanalysis techniques have been developed, but they are generic techniques that aren’t vastly more effective on these block ciphers than other ciphers of the same size.

And if the NSA really knows of completely novel techniques to break these ciphers that no one in academia ever explored, which is very unlikely, they can apply the same techniques to other widely used ciphers sharing the same construction.

Unlike the Dual-DRBG backdoor, there’s little room to hide a backdoor in plain sight in such ciphers. SIMON’s round constants are generated by a simple LFSR with a fixed primitive polynomial. The base value doesn’t come with a justification like “digits of pi”, but in that context, anything not showing signs of symmetry is fine. SPECK avoids constants almost entirely.

TLDR: after more than 13 years, extensive cryptanalysis exists, no practical backdoors have been found, and attacks generally align with what the designers claimed. The only expectations they don’t meet are cultural. After all that time, it’s time to move on and consider them for their properties and applications.

SIMON and SPECK are small, simple, and fast. They can be implemented in ~20 lines of code in any programming language, and will have good performance on a wide range of CPUs.

They are versatile, supporting block sizes of 32, 48, 64, 96 and 128 bits, with a key size from 64 to 256 bits. For a 128-bit block cipher, you’d better use AES. But for something smaller, they are a solid choice.

And if in spite of existing analysis, you still feel nervous about structural attacks and some edge-case distinguishers, there’s a simple, cheap addition you can make: key whitening (the FX/Even-Mansour construction). XOR the key before the first round and after the last round. This has been formally shown to improve security bounds under idealized models. Done.

Want to give them a spin? Try, for example, these easy to use implementations of SPECK, SIMON and SIMECK in Zig and Rust.

Should you use small block ciphers?

Generally, no. They are not generic ciphers that are safe to use in a wide range of scenarios. If they are large enough and the random number generator can be trusted, random identifiers are also a more secure option. Maybe dates, frame numbers, account identifiers and other numbers publicly leaked are not considered sensitive data, so you don’t have to worry about them at all. It all depends on your applications and protocols.

However, small block ciphers represent something to keep in your toolbox. You don’t have to systematically reach out to AES-GCM. But even if you do, maybe the public nonce leaks information? In that case, there’s a simple way to hide it. Use a small block cipher.