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:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
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/D1XZtRSIkqbvRQ3wgABmBgCAAAHhUIAAJeoAgAAASmCAARpFgIAAAIWQgABIkICAAAcZkIAAQkcAgAEBE3CAAJHdAIAAM6SQgAAJhoCAAAKAEA==
Date:   Fri, 9 Aug 2019 21:33:14 +0000
Message-ID: <MN2PR20MB29736FF8E67D83FEA5A52E14CAD60@MN2PR20MB2973.namprd20.prod.outlook.com>
References: <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>
 <MN2PR20MB29739B9D16130F5C06831C92CAD70@MN2PR20MB2973.namprd20.prod.outlook.com>
 <20190808171508.GA201004@gmail.com>
 <MN2PR20MB2973387C1A083138866EE45FCAD60@MN2PR20MB2973.namprd20.prod.outlook.com>
 <20190809171720.GC658@sol.localdomain>
 <MN2PR20MB2973BE617D7BC075BB7BB1ACCAD60@MN2PR20MB2973.namprd20.prod.outlook.com>
 <20190809205614.GB100971@gmail.com>
In-Reply-To: <20190809205614.GB100971@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: 7ed6626b-4f73-44c1-2655-08d71d112f7a
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2019 21:33:14.2349
 (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: rjwFuWAwC0kRK+BafFd5wT5mWlxKLbg0RV9D2RB7z3pqGTR93UrH4Mif0xUiC/+HodMeKBWHDfOjbOG4Q39UjGOU3bsynzyklWi4QuP0v0w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR20MB2303
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: Friday, August 9, 2019 10:56 PM
> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV gen=
eration
>=20
> On Fri, Aug 09, 2019 at 08:29:59PM +0000, Pascal Van Leeuwen wrote:
> > >
> > > There's no proof that other attacks don't exist.
> > >
> > As you can't prove something doesn't exist ...
>=20
> Of course you can, that's what the security proofs for crypto constructio=
ns
> always do.  They prove that no efficient attack exists (in some attack mo=
del)
> unless the underlying crypto primitives are weak.
>=20
> >
> > > If you're going to advocate
> > > for using it regardless, then you need to choose a different (weaker)=
 attack
> > > model, then formally prove that the construction is secure under that=
 model.
> > > Or show where someone else has done so.
> > >
> > I'm certainly NOT advocating the use of this. I was merely pointing out=
 a
> > legacy use case that happens to be very relevant to people stuck with i=
t,
> > which therefore should not be dismissed so easily.
> > And how this legacy use case may have further security implications (li=
ke
> > the tweak encryption being more sensitive than was being assumed, so yo=
u
> > don't want to run that through an insecure implementation).
>=20
> Obviously there are people already using bad crypto, whether this or some=
thing
> else, and they often need to continue to be supported.  I'm not disputing=
 that.
>=20
> What I'm disputing is your willingness to argue that it's not really that=
 bad,
> without a corresponding formal proof which crypto constructions always ha=
ve.
>=20
Real life designs require all kinds of trade-offs and compromises.
If you want to make something twice as expensive, you'd better have a=20
really solid reason for doing so. So yes, I do believe it is useful to
be sceptical and question these things. But I always listen to good=20
arguments, so just convince me I got it wrong *for my particular use
case* (I'm not generally interested in the generic case).

I mean, we were talking XTS here. Which is basically better-than-
nothing crypto anyway. It's one big compromise to be doing something
really fast without needing to expand the data. Good crypto would not
work on narrow blocks and/or include authentication as well ...

> - Eric


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