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
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