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

[Stephan Mueller <smueller@chronox.de>]

Am Montag, 20. April 2026, 19:47:13 Mitteleuropäische Sommerzeit schrieb Eric 
Biggers:

Hi Eric,

> 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? 

I see it being used by vendors that I work with. I neither have concrete 
numbers or do I know how many machines are covered by it.

For any personal operations, I use the XDRBG anyway that would be separately 
implemented and provided.

> Note that the only way to select it

The selection would always be done during compile time for those vendors.

> 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)?

The performance also implies that for a given number of bits, it uses less CPU 
cycles.


Ciao
Stephan