From 6f88f41eeb7d4ef34e4ddb133d10779a316da67f Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Sun, 19 Apr 2026 23:33:56 -0700 Subject: crypto: drbg - Remove support for CTR_DRBG Remove the support for CTR_DRBG. It's likely unused code, seeing as HMAC_DRBG is always enabled and prioritized over it unless NETLINK_CRYPTO is used to change the algorithm priorities. There's also no compelling reason to support more than one of [HMAC_DRBG, HASH_DRBG, CTR_DRBG]. By definition, callers cannot tell any difference in their outputs. And all are FIPS-certifiable, which is the only point of the kernel's NIST DRBGs anyway. Switching to CTR_DRBG doesn't seem all that compelling, either. While it's often the fastest NIST DRBG, it has several disadvantages: - CTR_DRBG uses AES. Some platforms don't have AES acceleration at all, causing a fallback to the table-based AES code which is very slow and can be vulnerable to cache-timing attacks. In contrast, HMAC_DRBG uses primitives that are consistently constant-time. - CTR_DRBG is usually considered to be somewhat less cryptographically robust than HMAC_DRBG. Granted, HMAC_DRBG isn't all that great either, e.g. given the negative result from Woodage & Shumow (2018) (https://eprint.iacr.org/2018/349.pdf), but that can be worked around. - CTR_DRBG is more complex than HMAC_DRBG, risking bugs. Indeed, while reviewing the CTR_DRBG code, I found two bugs, including one where it can return success while leaving the output buffer uninitialized. - The kernel's implementation of CTR_DRBG uses an "ctr(aes)" crypto_skcipher and relies on it returning the next counter value. That's fragile, and indeed historically many "ctr(aes)" crypto_skcipher implementations haven't done that. E.g. see commit 511306b2d075 ("crypto: arm/aes-ce - update IV after partial final CTR block"), commit fa5fd3afc7e6 ("crypto: arm64/aes-blk - update IV after partial final CTR block"), commit 371731ec2179 ("crypto: atmel-aes - Fix saving of IV for CTR mode"), commit 25baaf8e2c93 ("crypto: crypto4xx - fix ctr-aes missing output IV"), commit 334d37c9e263 ("crypto: caam - update IV using HW support"), commit 0a4491d3febe ("crypto: chelsio - count incomplete block in IV"), commit e8e3c1ca57d4 ("crypto: s5p - update iv after AES-CBC op end"). I.e., there were many years where the kernel's CTR_DRBG code (if it were to have actually been used) repeated outputs on some platforms. AES-CTR also uses a 128-bit counter, which creates overflow edge cases that are sometimes gotten wrong. E.g. see commit 009b30ac7444 ("crypto: vmx - CTR: always increment IV as quadword"). So, while switching to CTR_DRBG for performance reasons isn't completely out of the question (notably BoringSSL uses it), it would take quite a bit more work to create a solid implementation of it in the kernel, including a more solid implementation of AES-CTR itself (in lib/crypto/, with a scalar bit-sliced fallback, etc). Since HMAC_DRBG has always been the default NIST DRBG variant in the kernel and is in a better state, let's just standardize on it for now. Signed-off-by: Eric Biggers Acked-by: Geert Uytterhoeven # m68k Signed-off-by: Herbert Xu --- include/crypto/internal/drbg.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'include') diff --git a/include/crypto/internal/drbg.h b/include/crypto/internal/drbg.h index b4e5ef0be602..5d4174cc6a53 100644 --- a/include/crypto/internal/drbg.h +++ b/include/crypto/internal/drbg.h @@ -9,6 +9,9 @@ #ifndef _INTERNAL_DRBG_H #define _INTERNAL_DRBG_H +#include +#include + /* * Concatenation Helper and string operation helper * -- cgit v1.2.3