From: "Van Leeuwen, Pascal" <pvanleeuwen@rambus.com>
To: "Horia Geantă" <horia.geanta@nxp.com>,
"Andrei Botila (OSS)" <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-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Eric Biggers <ebiggers@kernel.org>
Subject: Re: [RFC] crypto: xts - limit accepted key length
Date: Thu, 5 Mar 2020 16:48:06 +0000 [thread overview]
Message-ID: <CY4PR0401MB365264BDC0F6ECE487E826A9C3E20@CY4PR0401MB3652.namprd04.prod.outlook.com> (raw)
In-Reply-To: <a9b2a676329c4905be6efe088cbb7663@DM6PR20MB2762.namprd20.prod.outlook.com>
>> 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>
next prev parent reply other threads:[~2020-03-05 16:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b8c0cbbf0cb94e389bae5ae3da77596d@DM6PR20MB2762.namprd20.prod.outlook.com>
2020-03-02 8:33 ` [RFC] crypto: xts - limit accepted key length Van Leeuwen, Pascal
2020-03-03 12:29 ` Andrei Botila
2020-03-03 12:35 ` Milan Broz
2020-03-03 13:03 ` Van Leeuwen, Pascal
[not found] ` <c69cebf0d6cb48ff93389d73dea6ba3e@DM6PR20MB2762.namprd20.prod.outlook.com>
2020-03-03 13:09 ` Van Leeuwen, Pascal
2020-03-05 15:22 ` Horia Geantă
[not found] ` <a9b2a676329c4905be6efe088cbb7663@DM6PR20MB2762.namprd20.prod.outlook.com>
2020-03-05 16:48 ` Van Leeuwen, Pascal [this message]
2020-03-02 8:16 Andrei Botila
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=CY4PR0401MB365264BDC0F6ECE487E826A9C3E20@CY4PR0401MB3652.namprd04.prod.outlook.com \
--to=pvanleeuwen@rambus.com \
--cc=andrei.botila@oss.nxp.com \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).