Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 11 Nov 2022 12:23:03 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Nicolai Stange <nstange@suse.de>
Cc:     "Elliott, Robert (Servers)" <elliott@hpe.com>,
        "David S. Miller" <davem@davemloft.net>,
        Vladis Dronov <vdronov@redhat.com>,
        Stephan Mueller <smueller@chronox.de>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] crypto: xts - restrict key lengths to approved
 values in FIPS mode
Message-ID: <Y23OJ79fZrbC/i1D@gondor.apana.org.au>
References: <20221108142025.13461-1-nstange@suse.de>
 <20221108142025.13461-2-nstange@suse.de>
 <MW5PR84MB1842EEC44A8CB6594D4D0CD0AB3F9@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
 <8735asfnmu.fsf@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8735asfnmu.fsf@suse.de>
Precedence: bulk

On Wed, Nov 09, 2022 at 11:06:17AM +0100, Nicolai Stange wrote:
>
> >From a quick glance, all of the above drivers merely convert some
> crypto_skcipher to a crypto_tfm before passing it to xts_check_key().
> 
> So I think these should all be made to call xts_verify_key() directly
> instead, the former xts_check_key() could then get dropped. But that's
> more of a cleanup IMO and would probably deserve a separate patch series
> on its own.

We should make sure both do the same thing though.  So either
change all the drivers or just change xts_check_key in your patch
in addition to xts_verify_key.

Cheers,
-- 
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