crypto: drbg - Remove support for CTR_DRBG

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 <ebiggers@kernel.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>