RE: [RFC] crypto: xts - limit accepted key length

["Van Leeuwen, Pascal" <pvanleeuwen@rambus.com>]

> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of Andrei Botila
> Sent: Monday, March 2, 2020 9:16 AM
> To: Herbert Xu <herbert@gondor.apana.org.au>; David S. Miller <davem@davemloft.net>
> Cc: linux-crypto@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [RFC] crypto: xts - limit accepted key length
>
> <<< External Email >>>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the
> sender/sender address and know the content is safe.
>
>
> From: Andrei Botila <andrei.botila@nxp.com>
>
> Currently in XTS generic implementation the valid key length is
> repesented by any length which is even. This is a deviation from
> the XTS-AES standard (IEEE 1619-2007) which allows keys equal
> to {2 x 16B, 2 x 32B} that correspond to underlying XTS-AES-{128, 256}
> algorithm. XTS-AES-192 is not supported as mentioned in commit
> b66ad0b7aa92 ("crypto: tcrypt - remove AES-XTS-192 speed tests")) or
> any other length beside these two specified.
>
> If this modification is accepted then other ciphers that use XTS mode
> will have to be modified (camellia, cast6, serpent, twofish).
>
> Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
> ---
>  include/crypto/xts.h | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/include/crypto/xts.h b/include/crypto/xts.h
> index 0f8dba69feb4..26e764a5ae46 100644
> --- a/include/crypto/xts.h
> +++ b/include/crypto/xts.h
> @@ -4,6 +4,7 @@
>
>  #include <crypto/b128ops.h>
>  #include <crypto/internal/skcipher.h>
> +#include <crypto/aes.h>
>  #include <linux/fips.h>
>
>  #define XTS_BLOCK_SIZE 16
> @@ -12,10 +13,10 @@ static inline int xts_check_key(struct crypto_tfm *tfm,
>                                 const u8 *key, unsigned int keylen)
>  {
>         /*
> -        * key consists of keys of equal size concatenated, therefore
> -        * the length must be even.
> +        * key consists of keys of equal size concatenated, possible
> +        * values are 32 or 64 bytes.
>          */
> -       if (keylen % 2)
> +       if (keylen != 2 * AES_MIN_KEY_SIZE && keylen != 2 * AES_MAX_KEY_SIZE)
>                 return -EINVAL;
>
>         /* ensure that the AES and tweak key are not identical */
> @@ -29,10 +30,10 @@ static inline int xts_verify_key(struct crypto_skcipher *tfm,
>                                  const u8 *key, unsigned int keylen)
>  {
>         /*
> -        * key consists of keys of equal size concatenated, therefore
> -        * the length must be even.
> +        * key consists of keys of equal size concatenated, possible
> +        * values are 32 or 64 bytes.
>          */
> -       if (keylen % 2)
> +       if (keylen != 2 * AES_MIN_KEY_SIZE && keylen != 2 * AES_MAX_KEY_SIZE)
>                 return -EINVAL;
>
>         /* ensure that the AES and tweak key are not identical */
> --
> 2.17.1

Hmm ... in principle IEEE-1619 also defines XTS *only* for AES. So by that  same
reasoning, you should also not allow any usage of XTS beyond AES. Yet it is
actually being actively used(?) with other ciphers in the Linux kernel. Which is
not wrong perse, as the construct works with any block cipher with a 128 bit
block size. And is secure as long as that blockcipher is secure.

So why not allow 192 bit AES keys? Or some keysize that some other algorithm
may require, as I'm not sure all ciphers it is used with have 128 or 256 bit keys.

The modulo 2 check was just to ensure you indeed provided 2 full cipher keys,
any other error checking was deferred to the cipher algorithm's setkey.

Note that such a change would also allow all hardware drivers implementing
xts to follow suit and report an error, otherwise they will fail the selftests ...

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.


** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>