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

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Apr 20, 2026 at 04:40:18PM +0200, Stephan Mueller wrote:
> Am Montag, 20. April 2026, 08:33:56 Mitteleuropäische Sommerzeit schrieb Eric 
> Biggers:
> 
> Hi Eric,
> 
> > 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.
> 
> Just as an FYI: the CTR DRBG implementation is used, because it provides 
> massive superior performance. The CTR DRBG implementation is lined up to use 
> the AES-CTR mode directly. If you have an accelerated implementation like AES-
> NI or ARM-CE, your performance increase is significant.
> 
> For example, on my M4 development system, the generation of 1GB of data from 
> the CTR DRBG takes 90ms whereas the HMAC DRBG takes more than 4 seconds.
> 
> The default of HMAC DRBG, however, was used since it has a simple logic and 
> smaller code.

I guess I have to ask: by "it is used", do you mean that it's used by a
significant number of users, or is it more of a personal thing where you
happen to be personally using it?  Note that the only way to select it
is directly by driver name (which has no in-kernel users), by running a
custom userspace program that uses NETLINK_CRYPTO to modify the
algorithm priorities.  I'm sure you know how to do the NETLINK_CRYPTO
thing, but this very much seems like an idiosyncratic expert-level
configuration that isn't really used in practice, similar to some other
things that you've added like CONFIG_CRYPTO_JITTERENTROPY_MEMSIZE_*.

And even if it's being used, does it really need to be?  Do you really
need more than 250 MB/s of "FIPS-approved" random numbers, and from the
kernel (not a userspace library)?

I also don't think we actually have much choice, given that we don't
currently have a reliably correct implementation of CTR_DRBG anyway, and
that takes priority over everything else.  As I explained in detail in
this patch, this just hasn't been something that's ever been done.  It
sometimes returns success on failure, it sometimes isn't constant-time,
and it used to repeat output on some platforms (and maybe even still
does).  Not particularly great properties for a RNG.

While a reliable implementation of CTR_DRBG is possible (BoringSSL does
it, for example), the reality is it would take quite a bit more work.

- Eric