Re: [PATCH 12/38] crypto: drbg - Remove support for CTR_DRBG

[Geert Uytterhoeven]

On Mon, 20 Apr 2026 at 08:41, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> 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 <ebiggers@xxxxxxxxxx>

>  arch/m68k/configs/amiga_defconfig          |   1 -
>  arch/m68k/configs/apollo_defconfig         |   1 -
>  arch/m68k/configs/atari_defconfig          |   1 -
>  arch/m68k/configs/bvme6000_defconfig       |   1 -
>  arch/m68k/configs/hp300_defconfig          |   1 -
>  arch/m68k/configs/mac_defconfig            |   1 -
>  arch/m68k/configs/multi_defconfig          |   1 -
>  arch/m68k/configs/mvme147_defconfig        |   1 -
>  arch/m68k/configs/mvme16x_defconfig        |   1 -
>  arch/m68k/configs/q40_defconfig            |   1 -
>  arch/m68k/configs/sun3_defconfig           |   1 -
>  arch/m68k/configs/sun3x_defconfig          |   1 -

Acked-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> # m68k

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds