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
