summaryrefslogtreecommitdiff
path: root/crypto/hmac.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2019-11-29 11:35:22 -0800
committerHerbert Xu <herbert@gondor.apana.org.au>2019-12-11 16:36:57 +0800
commita0a7e012fefacd001b642bdbcb4a53ade4c1dfd3 (patch)
tree6d9677c171a2c5efbb748dcdb1b5af26e233b64a /crypto/hmac.c
parentfa9f99989600de48b047f7361ffbbc866de20491 (diff)
downloadlinux-crypto-a0a7e012fefacd001b642bdbcb4a53ade4c1dfd3.tar.gz
linux-crypto-a0a7e012fefacd001b642bdbcb4a53ade4c1dfd3.zip
crypto: shash - allow essiv and hmac to use OPTIONAL_KEY algorithms
The essiv and hmac templates refuse to use any hash algorithm that has a ->setkey() function, which includes not just algorithms that always need a key, but also algorithms that optionally take a key. Previously the only optionally-keyed hash algorithms in the crypto API were non-cryptographic algorithms like crc32, so this didn't really matter. But that's changed with BLAKE2 support being added. BLAKE2 should work with essiv and hmac, just like any other cryptographic hash. Fix this by allowing the use of both algorithms without a ->setkey() function and algorithms that have the OPTIONAL_KEY flag set. Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'crypto/hmac.c')
-rw-r--r--crypto/hmac.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/crypto/hmac.c b/crypto/hmac.c
index 8b2a212e..377f0773 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -185,9 +185,9 @@ static int hmac_create(struct crypto_template *tmpl, struct rtattr **tb)
return PTR_ERR(salg);
alg = &salg->base;
- /* The underlying hash algorithm must be unkeyed */
+ /* The underlying hash algorithm must not require a key */
err = -EINVAL;
- if (crypto_shash_alg_has_setkey(salg))
+ if (crypto_shash_alg_needs_key(salg))
goto out_put_alg;
ds = salg->digestsize;