Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAE9cyGRzwN8AMzdf=E+rBgrhkDxyV52h8t_cBWgiXscvX_2UtQ@mail.gmail.com>
 <YJTkf0F5IZhqiXI5@sol.localdomain> <CAE9cyGTi9YpC9pcu5-MXtmXu_DM5FEVt9DYrM4AQWQMK7f0=zA@mail.gmail.com>
In-Reply-To: <CAE9cyGTi9YpC9pcu5-MXtmXu_DM5FEVt9DYrM4AQWQMK7f0=zA@mail.gmail.com>
From:   Kestrel seventyfour <kestrelseventyfour@gmail.com>
Date:   Fri, 7 May 2021 15:02:11 +0200
Message-ID: <CAE9cyGRCDP5dv1AJ_5LL5e9vJasuc1_AZFLjZnT-hwYE-CUUFQ@mail.gmail.com>
Subject: Fwd: xts.c and block size inkonsistency? cannot pass generic driver
 comparision tests
To:     linux-crypto@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Eric,

I agree, that it can't be built on top of the kernels CBC. But in the
hardware CBC, e.g. for encryption I set the IV (encrypted tweak), set
the hardwares aes mode to CBC and start the encrypt of a 16 byte
block, then do an additional xor after that -> result of that full
block is the same as XTS. Then I gfmul the tweak and repeat the
previous starting with setting the tweak as iv.
Doing that is much faster and much more efficient than using the
kernels xts on top of ecb(aes). But it introduces the problem that I
have somehow to handle the CTS after my walk loop that just processes
full blocks or multiples of that. And I am trying to figure out, what
the best way is to do that with the least amount of code in my driver.
I cannot set blocksize to 1, because then the block size comparison to
generic xts fails and If I set the walksize to 1, I get the alignment
and split errors and would have to handle the splits and
missalignments manually.
So actually I need a combination of what the walk does (handle
alignment and splits) plus getting the last complete and incomplete
block after walk_skcipher_done returns -EINVAL. At least thats my
current idea. I could just copy most of the code from xts, but there
is a lot of stuff, that is not needed, if I combine the hardware CBC
and xor to be XEX (XTS without the cipher text stealing).

Thanks.

Am Fr., 7. Mai 2021 um 08:56 Uhr schrieb Eric Biggers <ebiggers@kernel.org>:
>
> On Fri, May 07, 2021 at 07:57:01AM +0200, Kestrel seventyfour wrote:
> > Hi,
> >
> > I have also added xts aes on combining the old hardware cbc algorithm
> > with an additional xor and the gfmul tweak handling. However, I
> > struggle to pass the comparision tests to the generic xts
> > implementation.
>
> XTS can't be built on top of CBC, unless you only do 1 block at a time.
>
> It can be built on top of ECB, which is what the template already does.
>
> Before getting too far into your questions, are you sure that what you're trying
> to do actually makes sense?
>
> - Eric