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:     Milan Broz <gmazyland@gmail.com>,
        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>
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/D1XZtRSIkqbvRQ3wgABmBgCAAAHhUIAAJeoAgAAASmCAARpFgIAAAIWQgABIkICAAAcZkA==
Date:   Thu, 8 Aug 2019 13:23:10 +0000
Message-ID: <MN2PR20MB29739B9D16130F5C06831C92CAD70@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>
 <MN2PR20MB297328E243D74E03C1EF54ACCAD70@MN2PR20MB2973.namprd20.prod.outlook.com>
 <67b4f0ee-b169-8af4-d7af-1c53a66ba587@gmail.com>
In-Reply-To: <67b4f0ee-b169-8af4-d7af-1c53a66ba587@gmail.com>
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: 17e6f19b-2bc7-4ba6-d156-08d71c038f18
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 13:23:10.6183
 (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: fQ9oqv5+vgvNPTustlAoofM2r4BEzAKl/ZJv4/0KbpA+eiOdF0mWtJo1HDBi8M+DpdYDbqBYM5YSMWnBxDy7v4+eTIaGH7oWH7n2HYQCqjs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR20MB2895
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: Milan Broz <gmazyland@gmail.com>
> Sent: Thursday, August 8, 2019 2:53 PM
> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>; Eric Biggers <ebigge=
rs@kernel.org>
> 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
> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV gen=
eration
>=20
> On 08/08/2019 11:31, Pascal Van Leeuwen wrote:
> >> -----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.kern=
el.org;
> >> herbert@gondor.apana.org.au; agk@redhat.com; snitzer@redhat.com; dm-de=
vel@redhat.com;
> >> gmazyland@gmail.com
> >> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV =
generation
> >>
> >> 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 ha=
ve
> >>>> 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 us=
e cases
> >>> I've seen, the same key is used for both, as having 2 keys just incre=
ases
> >>> key  storage requirements and does not actually improve effective sec=
urity
> >>> (of the algorithm itself, implementation peculiarities like this one =
aside
> >>> :-), as  XEX has been proven secure using a single key. And the secur=
ity
> >>> proof for XTS actually builds on that while using 2 keys deviates fro=
m it.
> >>>
> >>
> >> This is a common misconception.  Actually, XTS needs 2 distinct keys t=
o be a
> >> CCA-secure tweakable block cipher, due to another subtle difference fr=
om XEX:
> >> XEX (by which I really mean "XEX[E,2]") builds the sequence of masks s=
tarting
> >> with x^1, while XTS starts with x^0.  If only 1 key is used, the inclu=
sion of
> >> the 0th power in XTS allows the attack described in Section 6 of the X=
EX paper
> >> (https://web.cs.ucdavis.edu/~rogaway/papers/offsets.pdf).
> >>
> > Interesting ... I'm not a cryptographer, just a humble HW engineer spec=
ialized
> > in implementing crypto. I'm basing my views mostly on the Liskov/Minema=
tsu
> > "Comments on XTS", who assert that using 2 keys in XTS was misguided.
> > (and I never saw any follow-on comments asserting that this view was wr=
ong ...)
> > On not avoiding j=3D0 in the XTS spec they actually comment:
> > "This difference is significant in security, but has no impact on effec=
tiveness
> > 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 perf=
ormance
> > and key storage reasons.
>=20
> There is already check in kernel for XTS "weak" keys (tweak and encryptio=
n keys must not be
> the same).
>=20
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/i=
nclude/crypto/xts.h#
> n27
>=20
> For now it applies only in FIPS mode... (and if I see correctly it is dup=
licated in all
> drivers).
>=20
I never had any need to look into FIPS for XTS before, but this actually ap=
pears
to be accurate. FIPS indeed *requires this*. Much to my surprise, I might a=
dd.
Still looking for some actual rationale that goes beyond suggestion and inn=
uendo=20
(and is not too heavy on the math ;-) though.


> Milan


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