On Wed, Jun 19, 2019 at 7:29 PM Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > This series creates an ESSIV template that produces a skcipher or AEAD > transform based on a tuple of the form '<skcipher>,<cipher>,<shash>' > (or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the > encapsulated sync or async skcipher/aead by passing through all operations, > while using the cipher/shash pair to transform the input IV into an ESSIV > output IV. > > This matches what both users of ESSIV in the kernel do, and so it is proposed > as a replacement for those, in patches #2 and #4. > > This code has been tested using the fscrypt test suggested by Eric > (generic/549), as well as the mode-test script suggested by Milan for > the dm-crypt case. I also tested the aead case in a virtual machine, > but it definitely needs some wider testing from the dm-crypt experts. > > Changes since v2: > - fixed a couple of bugs that snuck in after I'd done the bulk of my > testing > - some cosmetic tweaks to the ESSIV template skcipher setkey function > to align it with the aead one > - add a test case for essiv(cbc(aes),aes,sha256) > - add an accelerated implementation for arm64 that combines the IV > derivation and the actual en/decryption in a single asm routine > > Scroll down for tcrypt speed test result comparing the essiv template > with the asm implementation. Bare cbc(aes) tests included for reference > as well. Taken on a 2GHz Cortex-A57 (AMD Seattle) > > Code can be found here > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=essiv-v3 Thank you Ard for this work. It is very useful. I am testing this now with the essiv implementation inside CryptoCell. One possible future optimization this opens the door for is having the template auto-increment the sector number. This will allow the device manager or fscrypt code to ask for crypto services on buffer spanning over a single sector size and have the crypto code automatically increment the sector number when processing the buffer. This may potentially shave a few cycles because it can potentially turn multiple calls into the crypto API in one, giving the crypto code a larger buffer to work on. This is actually supported by CryptoCell hardware and to the best of my knowledge also by a similar HW from Qualcomm via out-of-tree patches found in the Android tree. If this makes sense to you perhaps it is a good idea to have the template format be: <skcipher>,<cipher>,<shash>, <sector size> Where for now we will only support a sector size of '0' (i.e. do not auto-increment) and later extend or am I over engineering? :-) Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom! -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
