linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolai Stange <nstange@suse.de>
To: Vladis Dronov <vdronov@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S . Miller" <davem@davemloft.net>,
	Nicolai Stange <nstange@suse.de>,
	Elliott Robert <elliott@hpe.com>,
	Stephan Mueller <smueller@chronox.de>,
	Eric Biggers <ebiggers@google.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/6] crypto: xts - drop xts_check_key()
Date: Thu, 05 Jan 2023 12:27:34 +0100	[thread overview]
Message-ID: <87bkndb4rd.fsf@suse.de> (raw)
In-Reply-To: <20221229211710.14912-3-vdronov@redhat.com> (Vladis Dronov's message of "Thu, 29 Dec 2022 22:17:06 +0100")

Hi Vladis,

Vladis Dronov <vdronov@redhat.com> writes:

> xts_check_key() is obsoleted by xts_verify_key(). Over time XTS crypto
> drivers adopted the newer xts_verify_key() variant, but xts_check_key()
> is still used by a number of drivers. Switch drivers to use the newer
> xts_verify_key() and make a couple of cleanups. This allows us to drop
> xts_check_key() completely and avoid redundancy.

nice work, thanks a lot for doing it!

There are two (obviously correct) cleanups which seem unrelated to
xts_verify_key(), namely in cvm_setkey() and
nitrox_aes_ctr_rfc3686_setkey(), see below.

But the commit message does say "and make a couple of cleanups" and
these changes certainly qualify as such. I just wanted to have it
mentioned.

Reviewed-by: Nicolai Stange <nstange@suse.de>

Thanks!

Nicolai


>
> Signed-off-by: Vladis Dronov <vdronov@redhat.com>
> Reviewed-by: Eric Biggers <ebiggers@google.com>
> ---

<snip>

> diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c b/drivers/crypto/cavium/cpt/cptvf_algs.c
> index 9eca0c302186..0b38c2600b86 100644
> --- a/drivers/crypto/cavium/cpt/cptvf_algs.c
> +++ b/drivers/crypto/cavium/cpt/cptvf_algs.c

<snip>

> @@ -289,8 +288,7 @@ static int cvm_validate_keylen(struct cvm_enc_ctx *ctx, u32 keylen)
>  static int cvm_setkey(struct crypto_skcipher *cipher, const u8 *key,
>  		      u32 keylen, u8 cipher_type)
>  {
> -	struct crypto_tfm *tfm = crypto_skcipher_tfm(cipher);
> -	struct cvm_enc_ctx *ctx = crypto_tfm_ctx(tfm);
> +	struct cvm_enc_ctx *ctx = crypto_skcipher_ctx(cipher);
>  
>  	ctx->cipher_type = cipher_type;
>  	if (!cvm_validate_keylen(ctx, keylen)) {

This change here and ...


> diff --git a/drivers/crypto/cavium/nitrox/nitrox_skcipher.c b/drivers/crypto/cavium/nitrox/nitrox_skcipher.c
> index 248b4fff1c72..138261dcd032 100644
> --- a/drivers/crypto/cavium/nitrox/nitrox_skcipher.c
> +++ b/drivers/crypto/cavium/nitrox/nitrox_skcipher.c

<snip>

> @@ -362,8 +361,7 @@ static int nitrox_aes_xts_setkey(struct crypto_skcipher *cipher,
>  static int nitrox_aes_ctr_rfc3686_setkey(struct crypto_skcipher *cipher,
>  					 const u8 *key, unsigned int keylen)
>  {
> -	struct crypto_tfm *tfm = crypto_skcipher_tfm(cipher);
> -	struct nitrox_crypto_ctx *nctx = crypto_tfm_ctx(tfm);
> +	struct nitrox_crypto_ctx *nctx = crypto_skcipher_ctx(cipher);
>  	struct flexi_crypto_context *fctx;
>  	int aes_keylen;
>

this one are not strictly related to xts_verify_key() AFAICS, but it's
fine to have them included nonetheless, IMO.


-- 
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)

  reply	other threads:[~2023-01-05 11:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-29 21:17 [PATCH v3 0/6] Trivial set of FIPS 140-3 related changes Vladis Dronov
2022-12-29 21:17 ` [PATCH v3 1/6] crypto: xts - restrict key lengths to approved values in FIPS mode Vladis Dronov
2022-12-29 21:17 ` [PATCH v3 2/6] crypto: xts - drop xts_check_key() Vladis Dronov
2023-01-05 11:27   ` Nicolai Stange [this message]
2022-12-29 21:17 ` [PATCH v3 3/6] crypto: xts - drop redundant xts key check Vladis Dronov
2023-01-05 11:16   ` Nicolai Stange
2022-12-29 21:17 ` [PATCH v3 4/6] crypto: testmgr - disallow plain cbcmac(aes) in FIPS mode Vladis Dronov
2022-12-29 21:17 ` [PATCH v3 5/6] crypto: testmgr - disallow plain ghash " Vladis Dronov
2022-12-29 21:17 ` [PATCH v3 6/6] crypto: testmgr - allow ecdsa-nist-p256 and -p384 " Vladis Dronov
2023-01-06 15:18 ` [PATCH v3 0/6] Trivial set of FIPS 140-3 related changes Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkndb4rd.fsf@suse.de \
    --to=nstange@suse.de \
    --cc=davem@davemloft.net \
    --cc=ebiggers@google.com \
    --cc=elliott@hpe.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smueller@chronox.de \
    --cc=vdronov@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).