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

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

[Van Leeuwen, Pascal]

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

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

[Andrei Botila]

On 3/2/2020 10:33 AM, Van Leeuwen, Pascal wrote:
>> -----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>
> 
Hi,

The problem here is that implementations adhering strictly to
the IEEE 1619-2007 standard will have problems when receiving
key sizes different than 256/512 bit. Currently in crypto/testmgr.c
when fuzz testing is enabled it generates random keys with sizes
such as 192 bits. This is a problem because it will check the
XTS SW implementation result with the one generated by the hardware
implementations and the test will fail if the hardware is adhering
strictly to the standard.
This is also the case for our CAAM accelerator which is accepting
only XTS-AES-{128, 256} and currently fails when fuzz testing is
enabled and it receives 192 bit keys.
Maybe we can find a solution to limit this key size check only for AES.

Regards,
Andrei

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

[Milan Broz]

On 02/03/2020 09:33, Van Leeuwen, Pascal wrote:
> 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.
Just FYI - yes, it is actively used with other ciphers.

There is a lot of LUKS devices that use Serpent or Twofish with XTS mode.

The same for TrueCrypt/VeraCrypt, here sometimes it is used also in cipher chain
(both native binaries or cryptsetup code use dm-crypt with crypto API here).

XTS mode is designed for storage encryption only - and at least for disk encryption
I have never seen request for 192bit keys...

Milan

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

[Van Leeuwen, Pascal]

> -----Original Message-----
> From: Milan Broz <gmazyland@gmail.com>
> Sent: Tuesday, March 3, 2020 1:36 PM
> To: Van Leeuwen, Pascal <pvanleeuwen@rambus.com>; Andrei Botila <andrei.botila@oss.nxp.com>; 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: Re: [RFC] crypto: xts - limit accepted key length
>
> <<< External Email >>>
> On 02/03/2020 09:33, Van Leeuwen, Pascal wrote:
> > 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.
> Just FYI - yes, it is actively used with other ciphers.
>
> There is a lot of LUKS devices that use Serpent or Twofish with XTS mode.
>
> The same for TrueCrypt/VeraCrypt, here sometimes it is used also in cipher chain
> (both native binaries or cryptsetup code use dm-crypt with crypto API here).
>
> XTS mode is designed for storage encryption only - and at least for disk encryption
> I have never seen request for 192bit keys...
>
Me neither ... but I was just pointing out that referring to the IEEE spec (for supporting
only 128 and 256 bit keys) makes no sense if you also support other blockciphers not
mentioned in that same IEEE spec.

The mode itself can obviously work with any 128 bit blockcipher, with any keysize.
So any limitation on that would be purely artificial IMHO.

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>

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

[Van Leeuwen, Pascal]

> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of Andrei Botila
> Sent: Tuesday, March 3, 2020 1:29 PM
> To: Van Leeuwen, Pascal <pvanleeuwen@rambus.com>; 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: Re: [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.
>
>
> On 3/2/2020 10:33 AM, Van Leeuwen, Pascal wrote:
> >> -----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.<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rambus.com&amp;data=01%7C01%7C%7C80ccb224
> 2d29487ed86908d7bf6e80f8%7Cdcb260f9022d44958602eae51035a0d0%7C0&amp;sdata=JPDMHKRQiM4UkJcNtm0HG2Viaqsa7VPy%2F
> gTt4HILWDk%3D&amp;reserved=0>
> >
> Hi,
>
> The problem here is that implementations adhering strictly to
> the IEEE 1619-2007 standard will have problems when receiving
> key sizes different than 256/512 bit. Currently in crypto/testmgr.c
> when fuzz testing is enabled it generates random keys with sizes
> such as 192 bits. This is a problem because it will check the
> XTS SW implementation result with the one generated by the hardware
> implementations and the test will fail if the hardware is adhering
> strictly to the standard.
> This is also the case for our CAAM accelerator which is accepting
> only XTS-AES-{128, 256} and currently fails when fuzz testing is
> enabled and it receives 192 bit keys.
> Maybe we can find a solution to limit this key size check only for AES.
>
> Regards,
> Andrei

But our hardware can do XTS with AES with 192 bit keys. For whatever that
is worth. Note that this is _not_ an  IEEE 1619-2007 implementation (which
would have to be AES only), it is a basic XTS mode wrapper implementation,
supporting any 128 bit blockcipher underneath. And, hence, all it's keysizes.

What is wrong with software fallback for the 192 bit keys in your driver?

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>

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

[Horia Geantă]

On 3/3/2020 3:09 PM, Van Leeuwen, Pascal wrote:
> What is wrong with software fallback for the 192 bit keys in your driver?
More code to maintain.

AES-XTS-192 should be:
-either rejected (since there's a standard in place) or
-at most made optional (allowing for implementations to *optionally* support
more key sizes), meaning crypto fuzz testing shouldn't fail.

Suggestions on how to do this?

Thanks,
Horia

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

[Van Leeuwen, Pascal]

>> What is wrong with software fallback for the 192 bit keys in your driver?
> More code to maintain.
>
That applies to many corner cases not relevant to and therefore not supported by "my" HW as well ...
From personal experience, it's not generally accepted as an excuse though.

> AES-XTS-192 should be:
> -either rejected (since there's a standard in place) or
>
There is a standard for storage encryption _using_ AES in XTS mode, i.e. IEEE-P1619, which indeed does not mention 192 bit keys.
But there is no _standard_ for _generic_ XTS mode that prohibits the use of keysizes of the underlying blockcipher.
There really is no good reason to disallow the use of 192 bit keys with AES for XTS. As the software implementation as well as other hardware implementations can do it just fine.
Also, making an exception specifically for one particular blockcipher (being AES) inside the XTS wrapper is pretty ugly.

> -at most made optional (allowing for implementations to *optionally* support
> more key sizes), meaning crypto fuzz testing shouldn't fail.
>
Agree that it is a major burden on hardware device drivers to support every possible corner of a generic software implementation though software fallback mechanisms. Some mechanism allowing hardware drivers some freedom not to support certain corner cases that are not relevant to the scenarios where the driver is _known_ to be actually used would be terribly nice.

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

** 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>

[RFC] crypto: xts - limit accepted key length

[Andrei Botila]

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