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
From:   Kestrel seventyfour <kestrelseventyfour@gmail.com>
Date:   Fri, 7 May 2021 07:57:01 +0200
Message-ID: <CAE9cyGRzwN8AMzdf=E+rBgrhkDxyV52h8t_cBWgiXscvX_2UtQ@mail.gmail.com>
Subject: 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,

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.

In detail, xts.c exposes the block size of the underlying algo, which
is AES_BLOCK_SIZE. But it does not use the walk functions, because
they do not work if the input is not dividable by blocksize. Now the
xts.c has its own implementation, but I wonder, if that implementation
should accept input sizes other than dividable by block size?

Actually if xts would only accept multiples of block size, the cipher
text stealing would be obsolete. If I use walksize=1, I get the issues
with the unaligned or splitted scatterlists.

I really would prefer using walk just returning the remaining bytes
instead of moving out with -EINVAL:
https://elixir.bootlin.com/linux/latest/source/crypto/skcipher.c#L360
Is that intentional? For me its not logical to allow any input size to
xts, but the walk functions return errors if there are inputs not a
multiple of block size. Furthermore, its a waste of resources to
process all previous walks and then return an error on the last walk?!

I would expect xts to work in a similar way as ecb and ignore extra bytes?
https://elixir.bootlin.com/linux/latest/source/crypto/ecb.c#L36

Or is the advice simply, implement xts to work as in xts.c without
using walks and not worry about the inkonsistencies?

Thanks,
D. Kestrel