It often starts with a small file I’m not planning to commit.

I’m trying something, so I write a test. Or I figure out how to deploy the project to one of my servers and put the commands in a script. It assumes my directory layout, my set of installed tools, and probably something I’ve forgotten to document, but it works for me. That’s all I need from it.

Then I add some notes about things to fix or try, along with an idea for a feature that might go nowhere. None of this is ready to publish, but it belongs with the project, so I keep it in the checkout.

After a while, my checkout looks pretty different from what someone gets by cloning the repository. The public code is there, along with all the little things that help me maintain it.

And those little things stick around. They show up every time I run git status, until I’ve learned to ignore them without really looking. I don’t put them in .gitignore, because I don’t necessarily want to publish their names either.

I don’t want someone reading a rough idea in my notes and treating it as a promise. Deployment instructions might also have sensitive stuff in them. And honestly, a useful script can be terrible code, which I don’t want to clean up for public review every time I need to use it.

I could add them to .git/info/exclude, which would make git status quieter. But then I switch machines, clone the project, and get exactly what I asked Git to keep: the public part. All my useful clutter stayed on the other laptop.

I’d like those files to have a history, and I’d like to push them somewhere and get them back with the rest of my work. Git already does all of this for every other file in the project.

I want to share as much of the project as I can. I also want to be able to save unfinished work without having to explain it to everyone who looks at the repository.

So I started exploring an idea: what if I could check these files into the same repository, but only people with a secret key would get them in their checkout?

I already had a lot of what I needed in Turbocrypt, a fast, portable file and directory encryption tool. I use it all the time to back up sensitive files remotely. I also use it to keep some directories on my laptop encrypted, with a password protecting the key. That way, no applications can just read through them unless I step in and unlock them first.

Git encryption has just been implemented, and it changes everything.

Getting private files into Git

Here’s how to add an untracked NOTES.md and an ops/ directory.

From inside the checkout, generate a key outside the repository and tell Turbocrypt to use it:

mkdir -p ~/.config/turbocrypt
turbocrypt keygen --password ~/.config/turbocrypt/secret.key
turbocrypt config set-key ~/.config/turbocrypt/secret.key
turbocrypt git init

Then add the files that should stay private:

turbocrypt git add NOTES.md ops/
git commit -m "Add maintainer files"
git push

After the push, NOTES.md and ops/deploy.sh stay in place, so the notes can be opened in an editor and the script can run as usual.

What actually went into Git is an encrypted copy of each file, under .enc/. Their names are encrypted, too, along with the list of private paths. Local exclude rules keep the readable copies out of commits, without adding their names to a public ignore file.

Privacy applies to individual paths. It doesn’t force private work into a separate repository or even a dedicated directory. Private source files can sit next to public source files, and a private AGENTS.md can stay at the repository root, where tools expect to find it.

The checkout keeps its normal layout. Editors, compilers, and other tools just open ordinary files, and there’s no filesystem to mount. Only the encrypted copies stored in Git live under .enc/. That’s the private overlay I wanted.

New helpers added to ops/ are covered by the directory rule, too. Turbocrypt’s Git hooks update the encrypted copies before commits and refresh the readable files after checkouts, merges, and rebases.

If only private files have changed, run this to update and stage the encrypted copies before committing:

turbocrypt git encrypt
git commit -m "Update maintainer files"
git push

turbocrypt git status shows which private files have changed.

On another machine, clone the repository like usual, copy the key over separately, and run this from the checkout:

turbocrypt git unlock

The notes and the deployment script show up at their original paths, ready to use. Their encrypted versions came through the same remote and the same history as the public code.

Someone cloning without the key still gets the public project and can build it or contribute without installing Turbocrypt. They get the encrypted store, too, but the private files don’t show up in their working directory.

Making room for another maintainer

My deployment script is probably useless to another maintainer who’s got a different setup. They can keep their own scripts in the same repository with a separate key.

Maintainers don’t have to agree on what belongs in a shared private directory, because each key gets its own area under .enc/.

Turbocrypt restores the files belonging to the checkout’s key and leaves the others encrypted, including their lists of private paths.

So several maintainers can push private files to the same repository, then unlock their own notes and tools in a fresh clone.

They start with turbocrypt git init --key ... when their key is new to the repository. The next time they clone it, they use turbocrypt git unlock --key ... to get their files back. Right now, each checkout uses one key.

An entire branch can be private, too. A forthcoming feature can be developed and pushed normally, then revealed once it’s finished.

Sharing a key also lets a team work on a feature before it’s ready to publish. If the code depends on an internal API that hasn’t reached production yet, the team can commit the prototype and its documentation while waiting for the rollout.

When it’s ready, turbocrypt git rm <path> takes a file out of private management. The readable copy stays on disk, ready for an ordinary git add and a public commit.

I’ve written before about what happens when people start picking apart unfinished experiments. You push a branch because it’s convenient, and suddenly people think you’ve announced the future of the project. I’d like to try an idea with another maintainer and drop it if it doesn’t work out. If it does, we can publish it when we’ve got something worth showing.

How this compares to git-crypt

Git-crypt implements a similar idea.

But the differences go much further than hiding names.

A file called plans-to-replace-the-database.md already tells people a lot, even if they can’t read a word of it. And I wanted my private files to show up alongside the public files, with Git tracking their encrypted copies separately.

Keeping the encrypted copies separate also makes accidentally publishing a private file harder. The readable paths are excluded from Git, and the commit hook refuses a private file that’s also tracked in clear. Git-crypt relies on public .gitattributes rules, which must be active before a sensitive file is added. Changing those rules can disable encryption.

Turbocrypt uses a fresh random nonce for every encrypted copy. Two files with identical contents don’t produce identical ciphertext. Git-crypt deliberately uses deterministic encryption, so equality is visible.

Turbocrypt also authenticates the relative path with the contents. Moving an encrypted entry to another path is detected, even if both paths use the same key.

For convenience, hooks need to run without a password prompt every time, so Git mode keeps an unlocked copy of the key in .git/turbocrypt/key, with restricted permissions. The password still protects the original key file.

I think this is cool and useful, and it can probably be useful to you, too. So, give it a try!

And it used to encrypt file names and encode the resulting ciphertext using Base91.

Why Base91? Because it’s a perfect fit for encrypted file names, producing strings that can be stored as valid files on Unix and macOS.

“But my filesystem can store arbitrary file names”! That may be true for some filesystems, but this is without taking libraries and applications into consideration. For example, the macOS Finder would not like this at all.

So, Base91 worked fine for encrypted file and directory names.

Then people asked for Windows support, where several characters in the Unix filesystem-safe alphabet are forbidden.

So, TurboCrypt is switching to Base84.

Something surprisingly not defined nor (apparently) used anywhere, even though it’s a perfect fit for anything that should be encoded as portable filesystem-safe names.

Why Base84?

There are 94 printable ASCII characters excluding the space. But Windows rules exclude nine of them:

< > : " / \ | ? *

That leaves 85.

But a name ending in a dot doesn’t work reliably through the Windows shell and ordinary file APIs.

Remove the dot as well, and we have 84 characters that can appear anywhere in a filename component. Microsoft documents these restrictions.

Dropping dots also avoids hidden names on Unix and the special names . and ...

Here’s the alphabet, in encoding order:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!#$%&'()+,-;=@[]^_`{}~

Every character is acceptable in a filename on the usual Linux, macOS and Windows filesystems. And by design, a Base84 name can never be a Windows device name.

These encrypted file names are designed to be generated by software and consumed by software. They are opaque names used for remote storage. Nobody is expected to type them, so all we want is filesystem compatibility and smaller expansion than Base64.

Packing the bits

zig-base84 is an implementation of Base84.

It emits groups of five characters. Five is the sweet spot: 84⁵ = 4,182,119,424, only 2.6% short of 2³².

It’s simple to implement, and that leaves enough room for a group to hold 32 bits about 95% of the time on uniformly random input, and 31 bits otherwise.

The encoder looks at the next 31 bits. If their value is below 84⁵ - 2³¹, there’s room for a 32nd bit. Otherwise, it consumes just those 31 bits. Either way, the value fits in five base-84 digits. Pretty straightforward.

On random input, that’s about 31.95 bits per group, or 6.39 bits per character. The output is about 25.2% larger than the binary input. Almost Base85.

These expansion rates ignore the final partial group; the averages assume random input:

An input filled with 0xff forces every full group to consume only 31 bits. That’s the worst case: about 29% expansion.

Most filesystems cap a name at 255 bytes. Since the alphabet is ASCII, that’s 255 characters. Five divides 255 exactly, so even a maximum-length name holds only complete groups, with no bits lost to a partial one. Base84 guarantees room for 197 bytes of input, compared with 191 for unpadded Base64.

Unix-only names

Unix filenames can contain most of the punctuation Windows rejects. NUL and / are forbidden inside a filename; the Linux pathname documentation lists the rules and filesystem-specific limits.

The filesystem variant in zig-base91 replaces the standard Base91 alphabet’s slash with an apostrophe. It packs about 6.51 bits per character on random input, giving roughly 23% expansion.

For Unix-only names, use that variant. Standard Base91 still contains /, and both alphabets contain characters Windows rejects.

Base91 is used in hf-mount-encrypted, which adds transparent encryption to the tool to mount Hugging Face buckets, because the backend runs Linux, so Windows compatibility is irrelevant.

Windows device names

Windows reserves device names such as CON, NUL and COM1, regardless of case.

The five-character packing in Base84 has a useful side effect: with the standard alphabet, the encoder can’t spell a reserved device name, even for short inputs.

A three-character output always ends with A through J. That rules out CON, PRN, AUX and NUL, regardless of case.

A four-character output always ends with an uppercase letter or a, b, c. It can’t end with a digit, so COM1 through COM9 and LPT1 through LPT9 are impossible too. The superscript digits Windows also reserves aren’t in the alphabet.

And the alphabet has no dots, so a reserved name followed by an extension is also impossible.

Unlike other schemes such as Base64, no padding or special handling is needed to avoid these names.

How about case-insensitive filesystems?

Base84 distinguishes uppercase and lowercase letters, so different encoded names can compare equal on a case-insensitive filesystem.

For encrypted names, the collision probability depends on how much pseudorandom data gets encoded. TurboCrypt pads short names to 16 bytes before applying HCTR2. Modeling that encryption as a random permutation gives us 128-bit ciphertexts even for the shortest names.

Those 16 bytes encode to 20 or 21 characters. Even pretending every character is a letter, there are at most 2²¹ spellings that differ only in case.

Each valid spelling represents at most one of the 2¹²⁸ possible inputs, so a conservative upper bound on a case collision between two distinct encrypted names is 2²¹ / 2¹²⁸ = 2^-107. And longer ciphertexts give tighter bounds.

For n distinct names in the same directory, the birthday bound gives a collision probability of at most n(n - 1) / 2¹⁰⁸. Even with a billion names, that’s below 3.1 × 10^-15. Negligible.

For example, here’s a 40-line Rust reproducer that takes 50 seconds to build with debug info and 1.5 seconds without it.

This reproducer was reduced from a crate (ed25519-compact) where enabling debug info made compilation ~40x slower, but the bug itself is broader and affects all Rust code compiled to WebAssembly to varying degrees.

This is actually a known LLVM bug that had already been reported and fixed for clang. But the fix is incomplete.

Debug info becomes records in the instruction list

Cargo has a debug setting to control debug info. debug = 2 asks LLVM for full DWARF information, which very few people use in practice with WebAssembly, but which people like to enable anyway (if only because debug = true is an alias for debug = 2).

This debugging data is designed for profiling a wasm binary and getting real symbol names in stack traces. It’s also the default for Rust’s dev profile.

Something important to understand first: LLVM represents a source variable’s location with a DBG_VALUE record.

The record says that, at this point in the generated code, a variable lives in a register, a stack slot, or a constant. It sits in LLVM’s machine-level intermediate representation, or MIR, and produces no code by itself.

But it’s relevant when code is moved. A debugger must see the right value, so every pass that moves an instruction has to move or update its DBG_VALUE records too.

With debug = 2, heavy inlining can produce hundreds of thousands of DBG_VALUE records in one function.

And when targeting WebAssembly, a lot of code has to be moved.

WebAssembly has to move values onto the stack

Unlike native targets, WebAssembly is a stack machine.

LLVM first generates instructions using named temporary registers, then a backend pass called “Register Stackify” moves values it can use onto the stack near the end of code generation.

A definition computes a value, while a use consumes it.

And when a definition has one use, Register Stackify can move that definition immediately before the use.

The value then stays on the wasm operand stack instead of passing through a local, which saves wasm code and runtime work.

This happens inside a basic block, a straight sequence of instructions with no branches into or out of its middle.

But as we saw before, moving a definition also means moving its debug records. This is where things start to suck.

The pass keeps rescanning the list it grows

Before it can move a definition, the pass scans from that definition to the end of its basic block for its debug records, stopping if the register is defined again.

It also scans from the definition to the place where the instruction will be inserted, collecting records for the variables it tracks.

Those are linear scans.

But repeating them for many definitions turns them into quadratic work: twice as many records can mean four times as much scanning. Yikes.

The pass also makes its own input larger as it runs.

When it sinks a definition, it leaves the old debug records in the instruction list with their locations blanked out instead of deleting them.

When a value is cheap to compute, such as a constant, it computes that value again at every use instead of carrying it around. Each copy gets fresh DBG_VALUE records. Re-yikes.

So the pass keeps adding records to the same list it keeps rescanning. It’s very inefficient and awful for large functions.

A small reproducer

That reproducer repeatedly squares a [u64; 5] through a chain of #[inline(always)] functions.

On my machine, this command:

cargo build --release --target=wasm32-unknown-unknown

produced:

The 1.55 seconds is the whole cargo build time with debug info off. Adding full debug info turns the same build into a 50-second wait. Ouch!

And rustc -Z time-llvm-passes shows where it goes.

With debug = 2, LLVM pass time was 50.85s: WebAssembly Register Stackify took 43.51s, or 85.6%, and Explicit Locals took 6.31s, or 12.4%. Everything else is negligible.

With debug = 0, total pass time was 1.42s. Register Stackify took 0.96s and Explicit Locals took 0.003s, making them roughly 45x and 2000x slower with debug info.

This is all due to the inefficient handling of DBG_VALUE records.

The crate looks small and innocent: it just produces one function with one basic block.

But by the time Register Stackify is done, it has about 90k real instructions, 267k DBG_VALUE records, and 355k lines of MIR. Explicit Locals isn’t broken. It’s a linear pass that receives 350k instructions instead of 90k. Pretty bad.

LLVM’s fix is incomplete

There’s already llvm/llvm-project issue #168326, which was reported against clang and describes the same problem.

It was closed on 2026-03-27 by commit fe990b9005260bcf4a5630b577483e954c6bb60e.

The way it works is that it counts a register’s DBG_VALUE uses, then stops the forward scan after it has found them all. The counter is provided by a use list, the compiler’s unordered list of every place a value is used.

But that doesn’t help Rust (TBH it does, but very little).

The catch is that, while moving values, Register Stackify can point an existing DBG_VALUE at a different register without moving the record itself.

And after enough copies, a record near the top of the block can refer to a register defined near the bottom.

It appears in that register’s use list, yet a forward scan from the definition can never reach it. The counter includes the earlier record, so it never reaches zero.

A better fix

Here’s a better fix as a single patch that can be applied to the LLVM code that currently ships with Rust.

It contains three independent changes.

The first change is in the WebAssembly debug-record helper.

It stops Register Stackify from reading to the end of a block when it doesn’t need to.

The compiler already keeps a list of every place a value is used, including the debug records that mention it, so it knows how many records it needs to find. The old code still read forward from the definition until it reached the end of the block. After copies, some records can sit above the definition.

A forward scan can never reach them, so its count never reaches zero and it always reads to the end. That’s why LLVM’s existing change doesn’t help this Rust case.

The patch makes the thing walk upward as well as forward. The upward walk counts off records above the definition, while the forward walk keeps the same order and still stops at another definition.

Once both walks have accounted for every record, they stop. The compiler finds the same records in the same order without reading the rest of the block.

That same first change also avoids building expensive lookup keys for records it will discard. While collecting records between two points, the old code built and hashed a full identifier for every record it passed, then usually threw it away because it described a variable it didn’t track.

Now it first asks whether it cares about that variable with one cheap comparison. That reduced hash-table lookups from 27.4M to 3.0M. Pretty significant.

The second change is a non-WebAssembly-specific change.

LLVM gives real instructions position numbers so it can compare their order without walking the instruction list. But debug records never get a position number, yet the old code looked each one up before learning that it wasn’t there. The patch just skips those useless lookups. And every target benefits from it, not just WebAssembly.

The third change is back in the WebAssembly pass.

It asks a cheaper question about whether one instruction always runs before another. The general-purpose helper answered by walking the block from the beginning every time. The instructions already have position numbers, so comparing two numbers gives the same answer.

These changes don’t affect the compiled code itself at all, so there are no runtime performance regressions or behavior changes.

Let’s benchmark the reproducer again

Here are llc -O3 -time-passes measurements on the reproducer’s bitcode, the compiled form of the program that LLVM reads:

With debug info disabled, Register Stackify takes 1.14s on this input. The remaining debug-info overhead in that pass is about 0.05 seconds.

End to end, debug = 2 fell from 50.56s to 2.72s.

And debug = 0 fell from 1.55s to 0.89s. Pretty cool.

Processing and emitting 267k debug records still costs time, but the quadratic blowup is gone.

Testing on real-world code

Does this affect code people actually compile? Yes.

I repeated the crate benchmark with common crates.

Every crate used the release profile with debug = 2 and codegen-units = 1.

I emitted LLVM bitcode for every crate with:

RUSTFLAGS="--emit=llvm-bc" cargo build --release --target=wasm32-unknown-unknown

Then I ran each module through both compilers:

llc -O3 -time-passes -filetype=obj -o /dev/null <crate>.bc

Both llc binaries came from the same source tree with the same build configuration. The patch was the only difference.

Cryptography

I benchmarked an app with a bunch of crypto crates: aegis, sha2, sha3, blake2, blake3, md-5, ripemd, chacha20poly1305, aes-gcm, argon2, curve25519-dalek, ed25519-compact, k256, p256, p384, ahash, etc.

ed25519-compact 2.4.0 alone went from 1683.4s to 23.2s in Register Stackify, and from 1884.9s to 48.2s for total code generation.

That’s 31 minutes of code generation for one ordinary crate, down to 48 seconds.

The patched compiler still spends 23 seconds in that pass. Once its field arithmetic is inlined, the crate really is enormous. The quadratic scan is what turned 23 seconds into half an hour.

Here’s a detailed benchmark for some crates:

For sha2, 88% of the crate’s entire WebAssembly code-generation time was in Register Stackify before the fix.

Non-crypto things

I also tried a bunch of compression crates (brotli, flate2, miniz_oxide, ruzstd, zopfli, libflate, lzma-rs, snap, bzip2-rs, zune-inflate, lz4_flex).

Register Stackify went from 0.51s to 0.19s, 2.6x faster.

I also tried linear algebra crates (nalgebra, glam, and cgmath), and compilation got 4.3x faster.

The bug shows up everywhere, but it really gets expensive when a function gets big.

The target (wasm32-unknown-unknown, wasm32-wasip1, etc.) also doesn’t make any difference.

Who pays for it today

Rust users targeting any wasm target with debug info enabled are affected, including the default dev profile and release profiles with debug = 2 (debug = 1 isn’t affected).

C and C++ users compiling wasm with clang and -g are affected too, which is how issue #168326 in LLVM first appeared.

More codegen units or no debug info work around the problem until the patch lands, but that’s not ideal.

Is it going to be fixed once Rust updates its LLVM fork to include the fix originally made for clang?

Let’s see:

Well… no. An LLVM update will definitely help, but not as much as the changes proposed here.

And Satoru Kanno (@satokan3) wrote a great explanation of the result in Japanese.

Here’s a walkthrough based on his blog post and my understanding of the results, in English.

TLDR: Don’t panic. It’s an incremental improvement to an impractical reduced-round attack. Full AES-128 remains unaffected.

But what’s interesting is how the researchers used an AI model to find the improvement.

What the result actually covers

Standard AES-128 has ten rounds.

But this attack stops after seven. So, this is not the real cipher. But studying reduced-round ciphers is a common practice in order to better understand the security margin of a primitive.

A better attack on seven rounds is useful research, but it says nothing alarming about the complete cipher.

The attack also needs about 2^105 carefully arranged plaintext blocks, all encrypted under the same unknown key. This is way outside the recommended (and pratical) limits of AES usage, and just streaming that many 16-byte blocks at 1 TB/s would take roughly 20 trillion years.

And an attacker would have to collect them from real network traffic. Plus, they’d need access to an encryption oracle and the ability to choose a vast number of specially structured inputs.

That’s a lot to ask! So to be clear: this scenario is completely unrealistic. There’s no practical attack here. AES remains fine.

How the research happened

Nasr and Carlini have long records in security research. In particular, they recently coauthored ExploitGym, which tests whether AI agents can turn real software vulnerabilities into working exploits.

For this project, they used a custom research scaffold, sponsored by Anthropic (AI usage cost alone for that task was evaluated to about $100,000)

It gave the model access to papers, code, and experiments, and let long searches continue between human prompts.

And the early runs concluded that AES had already been studied too thoroughly to leave an easy improvement.

So, the team kept the search focused: they changed the instructions, rejected easier targets, and pushed the model to work on a publishable attack against seven rounds.

Their scaffold even let the model modify parts of its own agent loop.

And after three days, the output from one run contained the idea that became the Möbius Bridge.

Finally, a few more days of experiments refined it into the attack described in the paper.

The paper says the model produced the bridge, the optimization techniques, and the correctness arguments. Pretty cool.

It’s important to note that the AI model did substantial work inside the system the researchers built, but it didn’t independently decide to study AES or publish a result.

Nasr and Carlini spent several hundred hours, nearly a month, checking the claims and writing the paper.

They’re the researchers responsible for the work. The Claude Mythos model was a tool they used.

The expensive byte guess

The new attack builds on a 2013 meet-in-the-middle attack.

A meet-in-the-middle attack computes forward from the plaintext and backward from the ciphertext, then looks for a match in the middle. And in this case, a large precomputed table describes a four-round core of AES.

To reach that core, the older attack had to guess selected bytes from the outer rounds.

And one of those bytes had 256 possible values. For every candidate at this stage, the attack tried all 256 values and rebuilt the data for a table lookup each time.

The Möbius Bridge

Now, here’s the cool part, the shortcut. The AES S-box made it possible.

Because the S-box isn’t an arbitrary lookup table: it first inverts each byte in a 256-element finite field, then applies a fixed affine transformation.

And at this stage, the two sides of the attack see different versions of the same collection.

If an offline difference is called d, the paper’s bridge identity is g = s^2 * d^-1 XOR s, where g is the corresponding online value and s is an unknown byte shared by the entire collection.

As a function of d, this is a particular Möbius transformation.

The researchers then take the reciprocals of the offline differences. If v = d^-1, the relationship becomes the affine map v -> s^2 * v XOR s.

The Möbius Bridge replaces the collection with a fingerprint that stays identical under that shared transformation. The individual values change, but the fingerprint doesn’t.

The attack can therefore check the precomputed table without trying all 256 values of the key byte first.

The formula in the diagram describes the relation between two collections when the surrounding key guesses are correct. It doesn’t describe complete AES states.

The bridge doesn’t remove the byte from the final key: it removes the 256-way guess from this table-lookup stage, and a later step recovers the byte.

Other key guesses remain, and bytes that pass through MixColumns don’t preserve the same convenient relation.

Removing the loop suggests a 256-fold speedup. But it’s important to note that computing the fingerprint is expensive, so some of that gain disappears.

After several optimizations, the estimated speedup is about 200 to 800 times. Pretty impressive, but once again, that has no practical impact.

The data still dominates

For the same 2^105 chosen plaintexts and a roughly 63 percent chance of success, the estimates are:

That’s a large reduction but the impossible 2^105 data requirement hasn’t changed, so data remains the dominant cost.

What has actually been tested

Obviously, the complete attack has never been run because it’s far too expensive. So, the researchers tested its components instead. See the code they released.

The researchers also ran an end-to-end attack on a toy cipher based on AES with a 24-bit key.

For full-size seven-round AES-128, they recovered 50 out of 50 planted keys, but it skipped the two parts that can’t be run at full scale.

It used the one table entry that should match and to identify the rare plaintext pair that the complete attack would have to find.

A Lean theorem checks the core bridge identity, while large computational experiments test the fingerprint’s behavior. Cool, but neither proves the complete attack.

We should emphasize that Anthropic published the work as a technical report rather than a peer-reviewed paper. Cryptographers outside Anthropic commented on an early draft, but broad independent review has only just begun. The full attack is too expensive to validate on actual hardware.

That being said, the work remains a clever incremental result in reduced-round AES cryptanalysis.

These results show that a capable AI model can be a useful tool when experienced people choose the problem, give it room to explore, and check every important claim.

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

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

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

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

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

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

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

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

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

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

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

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

A lookup table inside a register

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

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

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

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

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

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

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

Turning 256 values into 16 by 16

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

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

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

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

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

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

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

And here’s something interesting:

256 = 16 * 16

This is just a reversible change of coordinates.

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

A linear input transformation produces those components:

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

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

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

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

Inversion with small register tables

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

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

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

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

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

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

a XOR 0x63 = AES_SBOX[input]

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

Folding the rest of the round

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

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

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

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

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

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

output = m0 XOR m1 XOR m2 XOR m3

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

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

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

Just one final vector XOR restores 0x63.

We can finally AddRoundKey, which is a simple XOR.

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

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

Swizzling infinity

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

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

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

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

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

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

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

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

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

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