Progress modernizing the Linux kernel’s internal cryptography framework was a central topic at the Linux Security Summit North America 2026, held May 21 to 22 in Minneapolis. Eric Biggers, a longtime kernel crypto maintainer, walked through both the problems with the original crypto API and the state of the newer library API effort meant to replace it for most in-kernel callers, in a talk whose details have continued circulating through kernel development discussion into July.

The Problem with the Original Crypto API

The kernel’s traditional crypto API was designed around an asynchronous, request-object-and-callback model, so that hardware crypto accelerators could be used transparently alongside software implementations. That design makes sense for the small share of callers actually talking to offload hardware, but the large majority of in-kernel code that just needs to compute a hash or perform a cipher operation synchronously has been forced through the same heavyweight request-and-callback machinery regardless.

/* The traditional API forces synchronous callers through
   an asynchronous-shaped interface: allocate a request,
   set a completion callback, submit, then wait. */

Biggers walked through concrete examples showing how easy this makes it to introduce subtle bugs: mishandled error paths in the callback plumbing, request objects with lifetimes that are easy to get wrong, and API surface large enough that new kernel code frequently gets crypto usage subtly wrong even when the underlying cryptographic primitive is implemented correctly.

The Library API Alternative

The newer library API approach exposes cryptographic primitives as direct function calls, callable synchronously without allocating a request object or wiring up a completion callback, for the majority of callers that don’t need asynchronous hardware offload in the first place. Code that does need hardware acceleration can still use the original crypto API’s asynchronous machinery, but everything else gets a substantially simpler, harder-to-misuse interface.

/* The library API model: call the primitive directly */
sha256(data, len, digest);

This is a similar shape to library-style crypto APIs long available in userspace (OpenSSL’s EVP interface, for instance), just newly available for in-kernel callers who previously had no synchronous option at all.

Why This Took So Long

The original crypto API’s asynchronous design dates back to a period when in-kernel hardware crypto offload was a bigger practical concern than it is on most of today’s general-purpose hardware, where CPU-level instructions like AES-NI make software crypto fast enough that offload is less frequently necessary. Introducing a parallel, simpler API without breaking the existing asynchronous one for the callers that genuinely need it has been a multi-year, incremental migration rather than a single rewrite, converting call sites gradually as the library API’s coverage of primitives has grown.

Post-Quantum Crypto Context

This modernization effort is unfolding alongside separate work adding post-quantum primitives to the kernel; ML-KEM and X-Wing patches have been posted upstream as part of a broader push to get post-quantum key exchange mechanisms into the kernel’s crypto subsystem ahead of eventual protocol-level adoption. A cleaner, simpler internal crypto API makes it meaningfully easier to add and correctly wire up new primitives like these as they mature, rather than forcing every new algorithm through the older API’s full asynchronous surface.

What This Means for Kernel Developers

For most kernel subsystem maintainers who need a hash or cipher operation and don’t care about hardware offload, the practical upshot of this work is fewer opportunities to get crypto usage wrong, and less boilerplate to write and review in the first place. The migration remains ongoing rather than complete, so expect the library API’s primitive coverage, and the number of call sites converted over to it, to keep expanding across upcoming kernel releases.