All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolai Stange <nstange@suse.de>
To: "Elliott, Robert (Servers)" <elliott@hpe.com>
Cc: Nicolai Stange <nstange@suse.de>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"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
Date: Wed, 09 Nov 2022 11:39:19 +0100	[thread overview]
Message-ID: <87h6z8e7jc.fsf@suse.de> (raw)
In-Reply-To: <MW5PR84MB1842A19B7BDA70A7C81AFB98AB3F9@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM> (Robert Elliott's message of "Tue, 8 Nov 2022 17:12:21 +0000")

"Elliott, Robert (Servers)" <elliott@hpe.com> writes:

>> diff --git a/include/crypto/xts.h b/include/crypto/xts.h
> ...
>> @@ -35,6 +35,13 @@ static inline int xts_verify_key(struct crypto_skcipher
>> *tfm,
>>  	if (keylen % 2)
>>  		return -EINVAL;
>> 
>> +	/*
>> +	 * In FIPS mode only a combined key length of either 256 or
>> +	 * 512 bits is allowed, c.f. FIPS 140-3 IG C.I.
>> +	 */
>> +	if (fips_enabled && keylen != 32 && keylen != 64)
>> +		return -EINVAL;
>> +
>>  	/* ensure that the AES and tweak key are not identical */
>>  	if ((fips_enabled || (crypto_skcipher_get_flags(tfm) &
>>  			      CRYPTO_TFM_REQ_FORBID_WEAK_KEYS)) &&
>> --
>> 2.38.0
>
> arch/s390/crypto/aes_s390.c has similar lines:
>
> static int xts_aes_set_key(struct crypto_skcipher *tfm, const u8 *in_key,
>                            unsigned int key_len)
> {
>         struct s390_xts_ctx *xts_ctx = crypto_skcipher_ctx(tfm);
>         unsigned long fc;
>         int err;
>
>         err = xts_fallback_setkey(tfm, in_key, key_len);
>         if (err)
>                 return err;
>
>         /* In fips mode only 128 bit or 256 bit keys are valid */
>         if (fips_enabled && key_len != 32 && key_len != 64)
>                 return -EINVAL;
>
>
> xts_fallback_setkey will now enforce that rule when setting up the
> fallback algorithm keys, which makes the xts_aes_set_key check
> unreachable.

Good finding!

>
> If that fallback setup were not present, then a call to xts_verify_key
> might be preferable to enforce any other rules like the WEAK_KEYS
> rule.
>

So if this patch here would get accepted, I'd propose to remove the then
dead code from aes_s390 afterwards and make an explicit call to
xts_verify_key() instead.

Or shall I split out the XTS patch from this series here and post these
two changes separately then? Herbert, any preferences?

Thanks!

Nicolai

-- 
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:[~2022-11-09 10:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-08 14:20 [PATCH 0/4] Trivial set of FIPS 140-3 related changes Nicolai Stange
2022-11-08 14:20 ` [PATCH 1/4] crypto: xts - restrict key lengths to approved values in FIPS mode Nicolai Stange
2022-11-08 17:12   ` Elliott, Robert (Servers)
2022-11-09 10:39     ` Nicolai Stange [this message]
2022-11-11  4:22       ` Herbert Xu
2022-11-08 20:34   ` Elliott, Robert (Servers)
2022-11-09 10:06     ` Nicolai Stange
2022-11-11  4:23       ` Herbert Xu
2022-11-08 14:20 ` [PATCH 2/4] crypto: testmgr - disallow plain cbcmac(aes) " Nicolai Stange
2022-11-08 14:20 ` [PATCH 3/4] crypto: testmgr - disallow plain ghash " Nicolai Stange
2022-11-08 14:20 ` [PATCH 4/4] crypto: testmgr - allow ecdsa-nist-p256 and -p384 " Nicolai Stange
2022-12-21 15:24 ` [PATCH 0/4] Trivial set of FIPS 140-3 related changes Vladis Dronov
2022-12-21 20:46   ` Eric Biggers
2022-12-21 22:49     ` Vladis Dronov
2022-12-21 15:25 ` [PATCH 5/6] crypto: xts - drop xts_check_key() Vladis Dronov
2022-12-21 15:26 ` [PATCH 6/6] crypto: xts - drop redundant xts key check Vladis Dronov

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=87h6z8e7jc.fsf@suse.de \
    --to=nstange@suse.de \
    --cc=davem@davemloft.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.