You’ve probably spent hours trying to get the Linux kernel’s crypto API to work efficiently. You write a simple encryption operation, and suddenly you’re drowning in dynamic allocations, indirect calls, and layers of abstraction that seem designed to slow you down. You’re not alone—and you’re not the problem.
Eric Biggers, a Google engineer who spends his days inside this code, put it bluntly: the kernel’s crypto API is hard to use and slow. And the reason isn’t the math behind AES or ChaCha. It’s not the hardware limits. It’s a software architecture that has become its own worst enemy.
The bottleneck in modern cryptography isn’t the math—it’s the software architecture.
Think about it: every time you stream a video, send a message, or authenticate a transaction, somewhere a Linux server is doing crypto. That’s billions of operations per second. And each one is paying a hidden tax—a tax on legacy abstraction patterns that were designed for a different era, a different set of algorithms, and completely different hardware.
Here’s what’s actually happening under the hood. The kernel’s crypto API uses a generic abstraction layer that forces every algorithm to conform to a one-size-fits-all interface. That means dynamic memory allocations for every operation. It means indirect function calls that the CPU can’t predict. It means cache misses, branch mispredictions, and a thousand tiny cuts that add up to a measurable, systemic slowdown.
We’ve been told that abstraction is good. It hides complexity, it enables reuse. But after a decade of algorithmic evolution—hardware acceleration, SIMD instructions, specialized instructions like AES-NI—the abstraction itself has become the complexity. It’s now a cage that traps performance inside legacy design.
Every time a developer fights the crypto API, they’re fighting a ghost from 2002.
And the frustration is real. You want to use a modern algorithm like XChaCha20-Poly1305? The API forces you through the same bloated path as a legacy cipher. Want to leverage hardware offload? The abstraction hides it from you. The tools designed to help you have become the obstacle.
So whose fault is it? Nobody’s and everybody’s. The kernel moves slowly for good reasons—stability, security, backward compatibility. But the result is a system that incurs a hidden cost on every transaction. A cost that scales with every new server running Linux. A cost that the digital economy bears silently.
This isn’t a niche problem. Linux powers the cloud, the backbone of the internet, the edge devices. The crypto performance tax is real, and it’s growing as encryption becomes ubiquitous. We should be asking: why are we still paying it?
It’s time to stop blaming the algorithms. Stop blaming the hardware. The bottleneck is in the architecture—the abstraction that forgot why it was built. And the only way out is to recognize that abstraction is not free; it’s a debt that compounds.
The next time your code feels slow, look at the API you’re using. Chances are, you’re not the one with the problem. The problem is the ghost in the machine.
FAQ
Q: Isn't the crypto API slow because encryption itself is computationally expensive?
A: No. Modern algorithms like AES-NI or ChaCha20 are extremely fast on modern hardware. The bottleneck is the kernel's abstraction layer—dynamic allocations, indirect calls, and poor cache behavior—not the math.
Q: What's the practical impact of this performance tax on real-world applications?
A: Every cloud server, every encrypted web connection, every containerization system that uses kernel crypto pays a measurable slowdown. For high-throughput systems (e.g., CDNs, databases), this can mean 10–30% more CPU usage on crypto operations, directly increasing infrastructure costs.
Q: Should we just remove the abstraction layer and make everything direct?
A: That’s the contrarian take—but it would break compatibility and security. The better path is to redesign the API to expose hardware-specific paths while keeping a safe default, like how modern kernel subsystems (e.g., io_uring) handle async I/O.