RE: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation

[Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>]

> -----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 generation
> 
> 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 ...
> 
> Of course you can, that's what the security proofs for crypto constructions
> always do.  They prove that no efficient attack exists (in some attack model)
> unless the underlying crypto primitives are weak.
> 
> >
> > > 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 it,
> > which therefore should not be dismissed so easily.
> > And how this legacy use case may have further security implications (like
> > the tweak encryption being more sensitive than was being assumed, so you
> > don't want to run that through an insecure implementation).
> 
> Obviously there are people already using bad crypto, whether this or something
> else, and they often need to continue to be supported.  I'm not disputing that.
> 
> 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 have.
> 
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 
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 
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