; cry...@vger.kernel.org; dm-devel@redhat.com
> > Subject: Re: xts fuzz testing and lack of ciphertext stealing support
> >
> > I would argue that these cases are diametrically opposite: you
> > proposed to remove support for zero length input vectors from the
> > e
> -Original Message-
> From: Ard Biesheuvel
> Sent: Friday, July 19, 2019 7:35 AM
> To: Pascal Van Leeuwen
> Cc: Herbert Xu ; Milan Broz
> ; Horia Geanta ; linux-
> cry...@vger.kernel.org; dm-devel@redhat.com
> Subject: Re: xts fuzz testing and lack of cip
On Thu, 18 Jul 2019 at 19:03, Pascal Van Leeuwen
wrote:
>
> > > > For XTS, you have this additional curve ball being thrown in called the
> > > > "tweak".
> > > > For encryption, the underlying "xts" would need to be able to chain the
> > > > tweak,
> > > > from what I've seen of the source the
On Thu, Jul 18, 2019 at 04:35:26PM +, Pascal Van Leeuwen wrote:
>
> Tthen there's still the issue of advancing that last tweak. From what I've
> seen,
> the xts implementation does not output the last tweak so you would have to
> recompute it locally in cts.c as block_cipher_enc(iv) *
> > > For XTS, you have this additional curve ball being thrown in called the
> > > "tweak".
> > > For encryption, the underlying "xts" would need to be able to chain the
> > > tweak,
> > > from what I've seen of the source the implementation cannot do that.
> >
> > You simply use the underlying
> >
> > Hmmm ... so the generic CTS template would have to figure out whether it is
> > wrapped
> > around ECB, CBC, XTS or whatever and then adjust to that?
>
> That's not hard to do. Right now cts only supports cbc. IOW
> if you pass it anything else it will refuse to instantiate.
>
Ah, I
On Thu, 18 Jul 2019 at 17:51, Herbert Xu wrote:
>
> On Thu, Jul 18, 2019 at 03:43:28PM +, Pascal Van Leeuwen wrote:
> >
> > Hmmm ... so the generic CTS template would have to figure out whether it is
> > wrapped
> > around ECB, CBC, XTS or whatever and then adjust to that?
>
> That's not
On Thu, Jul 18, 2019 at 03:43:28PM +, Pascal Van Leeuwen wrote:
>
> Hmmm ... so the generic CTS template would have to figure out whether it is
> wrapped
> around ECB, CBC, XTS or whatever and then adjust to that?
That's not hard to do. Right now cts only supports cbc. IOW
if you pass it
> > In fact, using the current cts template around the current xts template
> > actually does NOT
> > implement standards compliant XTS at all, as the CTS *implementation* for
> > XTS is
> > different from the one for CBC as implemented by the current CTS template.
>
> The template is just a
On Thu, Jul 18, 2019 at 10:40:54AM +, Pascal Van Leeuwen wrote:
>
> In fact, using the current cts template around the current xts template
> actually does NOT
> implement standards compliant XTS at all, as the CTS *implementation* for XTS
> is
> different from the one for CBC as
On Thu, Jul 18, 2019 at 01:19:41PM +0200, Milan Broz wrote:
>
> Also, I would like to avoid another "just because it is nicer" module
> dependence (XTS->XEX->ECB).
> Last time (when XTS was reimplemented using ECB) we have many reports with
> initramfs
> missing ECB module preventing boot from
On 18/07/2019 12:40, Pascal Van Leeuwen wrote:
...
>> See the reference in generic code - the 3rd line - link to the IEEE standard.
>> We do not implement it properly - for more than 12 years!
>>
>
> Full XTS is XEX-TCB-CTS so the proper terminology for "XTS without CTS" would
> be XEX-TCB.
>
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Milan Broz
> Sent: Thursday, July 18, 2019 9:40 AM
> To: Herbert Xu ; Ard Biesheuvel
>
> Cc: Horia Geanta ; linux-cry...@vger.kernel.org;
> dm-devel@redhat.com
> Subject: Re
On Thu, Jul 18, 2019 at 09:28:03AM +0200, Ard Biesheuvel wrote:
>
> If we were adding XTS to the kernel today, then I would agree with
> you. But xts() has an established meaning now, and I don't think it
> makes sense to update all implementations for a theoretical use case,
> given that no
On 18/07/2019 09:21, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 09:15:39AM +0200, Ard Biesheuvel wrote:
>>
>> Not just the generic implementation: there are numerous synchronous
>> and asynchronous implementations of xts(aes) in the kernel that would
>> have to be fixed, while there are no
On Thu, 18 Jul 2019 at 09:22, Herbert Xu wrote:
>
> On Thu, Jul 18, 2019 at 09:15:39AM +0200, Ard Biesheuvel wrote:
> >
> > Not just the generic implementation: there are numerous synchronous
> > and asynchronous implementations of xts(aes) in the kernel that would
> > have to be fixed, while
On Thu, Jul 18, 2019 at 09:15:39AM +0200, Ard Biesheuvel wrote:
>
> Not just the generic implementation: there are numerous synchronous
> and asynchronous implementations of xts(aes) in the kernel that would
> have to be fixed, while there are no in-kernel users that actually
> rely on CTS. Also,
On Wed, 17 Jul 2019 at 19:28, Eric Biggers wrote:
>
> On Wed, Jul 17, 2019 at 05:09:31PM +, Horia Geanta wrote:
> > On 7/17/2019 1:16 AM, Eric Biggers wrote:
> > > Hi Horia,
> > >
> > > On Tue, Jul 16, 2019 at 05:46:29PM +, Horia Geanta wrote:
> > >> Hi,
> > >>
> > >> With fuzz testing
On Wed, Jul 17, 2019 at 05:09:31PM +, Horia Geanta wrote:
> On 7/17/2019 1:16 AM, Eric Biggers wrote:
> > Hi Horia,
> >
> > On Tue, Jul 16, 2019 at 05:46:29PM +, Horia Geanta wrote:
> >> Hi,
> >>
> >> With fuzz testing enabled, I am seeing xts(aes) failures on caam drivers.
> >>
> >>
On 7/17/2019 1:16 AM, Eric Biggers wrote:
> Hi Horia,
>
> On Tue, Jul 16, 2019 at 05:46:29PM +, Horia Geanta wrote:
>> Hi,
>>
>> With fuzz testing enabled, I am seeing xts(aes) failures on caam drivers.
>>
>> Below are several failures, extracted from different runs:
>>
>> [3.921654] alg:
20 matches
Mail list logo
