ltq-deu: add aes_xts algorithm
authorDaniel Kestrel <kestrel1974@t-online.de>
Thu, 24 Jun 2021 15:41:33 +0000 (17:41 +0200)
committerHauke Mehrtens <hauke@hauke-m.de>
Wed, 5 Jan 2022 23:23:08 +0000 (00:23 +0100)
commit43422deed3939073a2acc23fcc33e18ab3a11924
tree1df579c5a87df344f72a0d1b960443310d3845e2
parent006fee0dadd184aab8a1a18d629674f8f06e9eda
ltq-deu: add aes_xts algorithm

The lantiq AES hardware does not support the xts algorithm. Apart
from the cipher text stealing (XTS), the AES XTS implementation is
just an XOR with the IV, followed by AES ECB, followed by another
XOR with the IV and as such can be also implemented by using the
lantiq hardware's CBC AES implemention plus one additional XOR with
the IV in the driver. The output IV by CBC AES is also not usable
and the gfmul operation not supported by lantiq hardware. Both need
to be done in the driver too in addition to the IV treatment which is
the initial encryption by the other half of the input key and to
set the IV to the IV registers for every block.
In the generic kernel implementation, the block size for XTS is set
to 16 bytes, although the algorithm is designed to process any size
of input larger than 16 bytes. But since there is no way to
indicate a minimum input length, the block size is used. This leads
to certain issues when the skcipher walk functions are used, e.g.
processing less than block size bytes is not supported by calling
skcipher_walk_done.
The walksize is 2 AES blocks because otherwise for splitted input
or output data, less than blocksize is to be returned in some cases,
which cannot be processed. Another issue was that depending on
possible split of input/output data, just 16 bytes are returned while
less than 16 bytes were remaining, while cipher text stealing
requires 17 bytes or more for processing.
For example, if the input is 60 bytes and the walk is 48, then
processing 48 bytes leads to a return code of -EINVAL for
skcipher_walk_done. Therefor the processed counter is used to
figure out, when the actual cipher text stealing for the remaining
bytes less than blocksize needs to be applied.
Measured with cryptsetup benchmark, this XTS AES implementation is
about 19% faster than the kernels XTS implementation that uses the
hardware ECB AES (ca. 18.6 MiB/s vs. 15.8 MiB/s decryption 256b key).
The implementation was tested with the kernels crypto testmgr against
the kernels generic XTS AES implementation including extended tests.

Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
package/kernel/lantiq/ltq-deu/src/ifxmips_aes.c