Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
To:     Eric Biggers <ebiggers@kernel.org>
CC:     Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "agk@redhat.com" <agk@redhat.com>,
        "snitzer@redhat.com" <snitzer@redhat.com>,
        "dm-devel@redhat.com" <dm-devel@redhat.com>,
        "gmazyland@gmail.com" <gmazyland@gmail.com>
Subject: RE: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV
 generation
Thread-Topic: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV
 generation
Thread-Index: AQHVTOQKWnTPkdATo0i/D1XZtRSIkqbvRQ3wgABmBgCAAAHhUIAAJeoAgAAASmCAARpFgIAAAIWQ
Date:   Thu, 8 Aug 2019 09:31:08 +0000
Message-ID: <MN2PR20MB297328E243D74E03C1EF54ACCAD70@MN2PR20MB2973.namprd20.prod.outlook.com>
References: <20190807055022.15551-1-ard.biesheuvel@linaro.org>
 <MN2PR20MB297336108DF89337DDEEE2F6CAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
 <CAKv+Gu_jFW26boEhpnAZg9sjWWZf60FXSWuSqNvC5FJiL7EVSA@mail.gmail.com>
 <MN2PR20MB2973A02FC4D6F1D11BA80792CAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
 <CAKv+Gu8fgg=gt4LSnCfShnf0-PZ=B1TNwM3zdQr+V6hkozgDOA@mail.gmail.com>
 <MN2PR20MB29733EEF59CCD754256D5621CAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
 <20190808083059.GB5319@sol.localdomain>
In-Reply-To: <20190808083059.GB5319@sol.localdomain>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: verimatrix.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cdc865d3-69c8-462b-11e7-08d71be32528
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 09:31:08.9894
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dcb260f9-022d-4495-8602-eae51035a0d0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BvuyYBOZZeY1FiIFR6ohwofHAe5Ez1T4maX7zTNZ9ikTb2cJKhP8tDuBWtTAEWlEBcFetkRtiiJjbP6DNcGMhCWjt6X/PTqL91K+/Q144bE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR20MB3149
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

> -----Original Message-----
> From: Eric Biggers <ebiggers@kernel.org>
> Sent: Thursday, August 8, 2019 10:31 AM
> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; linux-crypto@vger.kernel.=
org;
> herbert@gondor.apana.org.au; agk@redhat.com; snitzer@redhat.com; dm-devel=
@redhat.com;
> gmazyland@gmail.com
> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV gen=
eration
>=20
> On Wed, Aug 07, 2019 at 04:14:22PM +0000, Pascal Van Leeuwen wrote:
> > > > > In your case, we are not dealing with known plaintext attacks,
> > > > >
> > > > Since this is XTS, which is used for disk encryption, I would argue
> > > > we do! For the tweak encryption, the sector number is known plainte=
xt,
> > > > same as for EBOIV. Also, you may be able to control data being writ=
ten
> > > > to the disk encrypted, either directly or indirectly.
> > > > OK, part of the data into the CTS encryption will be previous ciphe=
rtext,
> > > > but that may be just 1 byte with the rest being the known plaintext=
.
> > > >
> > >
> > > The tweak encryption uses a dedicated key, so leaking it does not hav=
e
> > > the same impact as it does in the EBOIV case.
> > >
> > Well ... yes and no. The spec defines them as seperately controllable -
> > deviating from the original XEX definition - but in most practicle use =
cases
> > I've seen, the same key is used for both, as having 2 keys just increas=
es
> > key  storage requirements and does not actually improve effective secur=
ity
> > (of the algorithm itself, implementation peculiarities like this one as=
ide
> > :-), as  XEX has been proven secure using a single key. And the securit=
y
> > proof for XTS actually builds on that while using 2 keys deviates from =
it.
> >
>=20
> This is a common misconception.  Actually, XTS needs 2 distinct keys to b=
e a
> CCA-secure tweakable block cipher, due to another subtle difference from =
XEX:
> XEX (by which I really mean "XEX[E,2]") builds the sequence of masks star=
ting
> with x^1, while XTS starts with x^0.  If only 1 key is used, the inclusio=
n of
> the 0th power in XTS allows the attack described in Section 6 of the XEX =
paper
> (https://web.cs.ucdavis.edu/~rogaway/papers/offsets.pdf).
>=20
Interesting ... I'm not a cryptographer, just a humble HW engineer speciali=
zed
in implementing crypto. I'm basing my views mostly on the Liskov/Minematsu
"Comments on XTS", who assert that using 2 keys in XTS was misguided.=20
(and I never saw any follow-on comments asserting that this view was wrong =
...)
On not avoiding j=3D0 in the XTS spec they actually comment:
"This difference is significant in security, but has no impact on effective=
ness=20
for practical applications.", which I read as "not relevant for normal use"=
.

In any case, it's frequently *used* with both keys being equal for performa=
nce
and key storage reasons.

> Of course, it's debatable what this means *in practice* to the usual XTS =
use
> cases like disk encryption, for which CCA security may not be critical...=
  But
> technically, single-key XTS isn't secure under as strong an attack model =
as XEX.
>=20
Well, technically the XTS specification does not actually mandate that j sh=
ould
start at 0 (!), although that's what the vectors and example code suggest .=
..

> - Eric

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com