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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CY4PR0401MB365264BDC0F6ECE487E826A9C3E20@CY4PR0401MB3652.namprd04.prod.outlook.com>
Date:   Thu, 5 Mar 2020 16:48:06 +0000
From:   "Van Leeuwen, Pascal" <pvanleeuwen@...bus.com>
To:     Horia Geantă <horia.geanta@....com>,
        "Andrei Botila (OSS)" <andrei.botila@....nxp.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>
CC:     "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Eric Biggers <ebiggers@...nel.org>
Subject: Re: [RFC] crypto: xts - limit accepted key length

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