On 12/31/2019 5:29 AM, Eric Biggers wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to > make the ->setkey() functions provide more information about errors. > > However, no one actually checks for this flag, which makes it pointless. > > Also, many algorithms fail to set this flag when given a bad length key. > Reviewing just the generic implementations, this is the case for > aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309, > rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably > many more in arch/*/crypto/ and drivers/crypto/. > > Some algorithms can even set this flag when the key is the correct > length. For example, authenc and authencesn set it when the key payload > is malformed in any way (not just a bad length), the atmel-sha and ccree > drivers can set it if a memory allocation fails, and the chelsio driver > sets it for bad auth tag lengths, not just bad key lengths. > > So even if someone actually wanted to start checking this flag (which > seems unlikely, since it's been unused for a long time), there would be > a lot of work needed to get it working correctly. But it would probably > be much better to go back to the drawing board and just define different > return values, like -EINVAL if the key is invalid for the algorithm vs. > -EKEYREJECTED if the key was rejected by a policy like "no weak keys". > That would be much simpler, less error-prone, and easier to test. > > So just remove this flag. > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> Reviewed-by: Horia Geantă <horia.geanta@xxxxxxx> for caam and talitos drivers. Thanks, Horia
