mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-07-28 07:59:29 -04:00
6f88f41eeb
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 commit511306b2d0("crypto: arm/aes-ce - update IV after partial final CTR block"), commitfa5fd3afc7("crypto: arm64/aes-blk - update IV after partial final CTR block"), commit371731ec21("crypto: atmel-aes - Fix saving of IV for CTR mode"), commit25baaf8e2c("crypto: crypto4xx - fix ctr-aes missing output IV"), commit334d37c9e2("crypto: caam - update IV using HW support"), commit0a4491d3fe("crypto: chelsio - count incomplete block in IV"), commite8e3c1ca57("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 commit009b30ac74("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 <ebiggers@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>