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) * alpha^j
On Thu, Jul 18, 2019 at 10:52:01AM -0400, Mike Snitzer wrote:
> On Wed, Jul 17 2019 at 11:25pm -0400,
> Ming Lei wrote:
>
> > dm-rq needs to free request which has been dispatched and not completed
> > by underlying queue. However, the underlying queue may have allocated
> > private stuff for thi
The pull request you sent on Thu, 18 Jul 2019 16:53:08 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> tags/for-5.3/dm-changes-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3bfe1fc46794631366faa3ef075e1b0ff7ba120a
Thank you!
--
Hi Linus,
When I sent my pull last Friday I had overlooked some email that Nikos
(cc'd) sent that same morning concerning review of my dm-snapshot
discard changes that were merged over the weekend. In addition, Nikos
inquired about his dm-kcopyd subjob size default adjustment I had
requested some
> > > 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 s
On Thu, Jul 18, 2019 at 06:19:24PM +0200, Ard Biesheuvel wrote:
>
> Note that for software algorithms such as the bit sliced NEON
> implementation of AES, which can only operate on 8 AES blocks at a
> time, doing the final 2 blocks sequentially is going to seriously
> impact performance. This means
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 hard
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 a
> > 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 nam
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 implemented
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 AE
On Wed, Jul 17 2019 at 11:25pm -0400,
Ming Lei wrote:
> dm-rq needs to free request which has been dispatched and not completed
> by underlying queue. However, the underlying queue may have allocated
> private stuff for this request in .queue_rq(), so dm-rq will leak the
> request private part.
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.
> But
> -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: xts fuzz testing and lack of cip
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 portab
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 in-kern
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 ther
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, i
On Thu, 18 Jul 2019 at 08:52, Herbert Xu wrote:
>
> On Wed, Jul 17, 2019 at 08:08:27PM +0200, Ard Biesheuvel wrote:
> >
> > Since the kernel does not support CTS for XTS any way, and since no
> > AF_ALG users can portably rely on this, I agree with Eric that the
> > only sensible way to address th
21 matches
Mail list logo
