aboutsummaryrefslogtreecommitdiffstats
path: root/toolchain/kernel-headers
diff options
context:
space:
mode:
authorDaniel Kestrel <kestrel1974@t-online.de>2021-06-24 17:41:33 +0200
committerHauke Mehrtens <hauke@hauke-m.de>2022-01-06 00:23:08 +0100
commit43422deed3939073a2acc23fcc33e18ab3a11924 (patch)
tree1df579c5a87df344f72a0d1b960443310d3845e2 /toolchain/kernel-headers
parent006fee0dadd184aab8a1a18d629674f8f06e9eda (diff)
downloadupstream-43422deed3939073a2acc23fcc33e18ab3a11924.tar.gz
upstream-43422deed3939073a2acc23fcc33e18ab3a11924.tar.bz2
upstream-43422deed3939073a2acc23fcc33e18ab3a11924.zip
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>
Diffstat (limited to 'toolchain/kernel-headers')
0 files changed, 0 insertions, 0 deletions