Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 11 Dec 2019 17:42:23 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     linux-crypto@vger.kernel.org
Subject: Re: [PATCH] crypto: shash - allow essiv and hmac to use OPTIONAL_KEY
 algorithms
Message-ID: <20191211094223.rhtnupwkgidjla2m@gondor.apana.org.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191129193522.52513-1-ebiggers@kernel.org>
Organization: Core
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Eric Biggers <ebiggers@kernel.org> wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> 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>
> ---
> crypto/essiv.c                 | 2 +-
> crypto/hmac.c                  | 4 ++--
> crypto/shash.c                 | 3 +--
> include/crypto/internal/hash.h | 6 ++++++
> 4 files changed, 10 insertions(+), 5 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt