Progress in modernizing kernel cryptography [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
Edition Return to the Front page
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
Progress in modernizing kernel cryptography
By Joe Brockmeier<br>July 8, 2026
LSS NA
At the 2026 Linux Security Summit North America, Eric Biggers spoke about<br>some of the problems with the kernel's cryptography framework, as well<br>as the recent progress in adding library APIs to allow developers to<br>use cryptographic functions without using the traditional crypto<br>API. He walked through a couple of examples to demonstrate the<br>frailty of the original API and showed how the new library API made<br>life easier for developers and kernel maintainers.
Biggers began by introducing himself. He is a maintainer of the crypto and<br>cyclic redundancy check (CRC) library code in the Linux kernel, as<br>well as of the fscrypt<br>library and fs-verity<br>support layer. He<br>said that he was grouping CRCs in with crypto because "they are<br>very similar from an implementation perspective" and the code was<br>for the kernel itself to use—user space has its own code. "It's<br>for all the kernel features that use these algorithms and need to<br>execute them in kernel mode." The use cases, he said, range from storage or network<br>encryption to generating random numbers, checking firmware integrity,<br>protecting against denial-of-service attacks, and more.
Traditional API
The Linux kernel has had what Biggers called the traditional crypto API, found in the top-level crypto<br>directory in the kernel tree, since 2002. It includes<br>cryptographic algorithms as well as some non-cryptographic algorithms<br>such as CRC. Unfortunately, he said, "this traditional crypto<br>API is not working well. It's complex, it's hard to use, and it's<br>often quite slow". That has always been true, he said, but it has<br>gotten worse over time.
$ sudo subscribe today
Subscribe today and elevate your LWN privileges. You’ll have<br>access to all of LWN’s high-quality articles as soon as they’re<br>published, and help support LWN in the process. Act now and you can start with a free trial subscription.
The traditional API does not match what most kernel developers<br>want, he said, and has not kept up with hardware: "Specifically, it<br>isn't well optimized for the CPU-based acceleration that modern<br>systems use." He also said that the framework was outdated and that<br>the API does not work well for newer algorithms and implementation<br>strategies.
To prove the point, he said he would show a couple of examples of<br>using a crypto algorithm in the kernel and "why the traditional<br>crypto API isn't all that great". He began with<br>computing a message authentication code (MAC) with a key and some data<br>using HMAC-SHA256, "one of the most common MAC algorithms". The<br>code is from on slides five and six in his presentation.
static int calc_hmac(const u8 *key, size_t keylen, const u8 *data, size_t datalen, u8 out[32])<br>struct crypto_shash *tfm;<br>int err;
tfm = crypto_alloc_shash("hmac(sha256)", 0, 0);<br>if (IS_ERR(tfm)) {<br>pr_err("Failed to allocate hmac(sha256): %ld\n", PTR_ERR(tfm));<br>return PTR_ERR(tfm);
To use the traditional crypto API to get the MAC value, he<br>explained, the first thing to do is to dynamically allocate a<br>crypto_shash object for HMAC-SHA256 by passing the name of<br>the algorithm as a string. Then, one has to check<br>for errors, "since this step can and often does fail".
err = crypto_shash_setkey(tfm, key, keylen);<br>if (!err) {<br>SHASH_DESC_ON_STACK(desc, tfm);
desc->tfm = tfm;<br>err = crypto_shash_digest(desc, data, datalen, out);<br>shash_desc_zero(desc);<br>if (err)<br>pr_err("Failed to calculate HMAC-SHA256 value: %d\n", err);<br>crypto_free_shash(tfm);<br>return err;
The next step is to set the key on the crypto_shash object. That<br>step can also fail, so more error-checking code is required. Then it<br>is necessary to allocate a synchronous hash descriptor; he said<br>that the easiest way to do that is to use the<br>SHASH_DESC_ON_STACK() macro. After that, initialize the hash<br>descriptor by setting the pointer to the crypto_shash. After all that,<br>then it's time to call the function that actually computes the MAC<br>value. Once that is done, clear sensitive data from the stack by<br>zeroizing the<br>hash descriptor, check for errors, and free the<br>crypto_shash.
Biggers said that this code "sort of works" but it is common<br>for bugs to be found after such code is merged because allocating the<br>crypto_shash fails on some systems. The fix for that is to make sure<br>that CRYPTO_HMAC and CRYPTO_SHA256 are enabled in<br>the Kconfig options. "This part is often overlooked because the<br>algorithms are loaded by name, so there's no link-time dependency on<br>them." The code builds fine, but fails at run time and<br>only on some systems. And if a developer wants the code to run in an<br>early init call? "They're still out of luck; there's no way to do<br>that with the traditional API because the...