* xts.c and block size inkonsistency? cannot pass generic driver comparision tests @ 2021-05-07 5:57 Kestrel seventyfour 2021-05-07 6:55 ` Eric Biggers 0 siblings, 1 reply; 4+ messages in thread From: Kestrel seventyfour @ 2021-05-07 5:57 UTC (permalink / raw) To: linux-crypto 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xts.c and block size inkonsistency? cannot pass generic driver comparision tests 2021-05-07 5:57 xts.c and block size inkonsistency? cannot pass generic driver comparision tests Kestrel seventyfour @ 2021-05-07 6:55 ` Eric Biggers [not found] ` <CAE9cyGTi9YpC9pcu5-MXtmXu_DM5FEVt9DYrM4AQWQMK7f0=zA@mail.gmail.com> 0 siblings, 1 reply; 4+ messages in thread From: Eric Biggers @ 2021-05-07 6:55 UTC (permalink / raw) To: Kestrel seventyfour; +Cc: linux-crypto 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAE9cyGTi9YpC9pcu5-MXtmXu_DM5FEVt9DYrM4AQWQMK7f0=zA@mail.gmail.com>]
* Fwd: xts.c and block size inkonsistency? cannot pass generic driver comparision tests [not found] ` <CAE9cyGTi9YpC9pcu5-MXtmXu_DM5FEVt9DYrM4AQWQMK7f0=zA@mail.gmail.com> @ 2021-05-07 13:02 ` Kestrel seventyfour 2021-05-07 18:56 ` Eric Biggers 0 siblings, 1 reply; 4+ messages in thread From: Kestrel seventyfour @ 2021-05-07 13:02 UTC (permalink / raw) To: linux-crypto Hi Eric, I agree, that it can't be built on top of the kernels CBC. But in the hardware CBC, e.g. for encryption I set the IV (encrypted tweak), set the hardwares aes mode to CBC and start the encrypt of a 16 byte block, then do an additional xor after that -> result of that full block is the same as XTS. Then I gfmul the tweak and repeat the previous starting with setting the tweak as iv. Doing that is much faster and much more efficient than using the kernels xts on top of ecb(aes). But it introduces the problem that I have somehow to handle the CTS after my walk loop that just processes full blocks or multiples of that. And I am trying to figure out, what the best way is to do that with the least amount of code in my driver. I cannot set blocksize to 1, because then the block size comparison to generic xts fails and If I set the walksize to 1, I get the alignment and split errors and would have to handle the splits and missalignments manually. So actually I need a combination of what the walk does (handle alignment and splits) plus getting the last complete and incomplete block after walk_skcipher_done returns -EINVAL. At least thats my current idea. I could just copy most of the code from xts, but there is a lot of stuff, that is not needed, if I combine the hardware CBC and xor to be XEX (XTS without the cipher text stealing). Thanks. Am Fr., 7. Mai 2021 um 08:56 Uhr schrieb Eric Biggers <ebiggers@kernel.org>: > > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Fwd: xts.c and block size inkonsistency? cannot pass generic driver comparision tests 2021-05-07 13:02 ` Fwd: " Kestrel seventyfour @ 2021-05-07 18:56 ` Eric Biggers 0 siblings, 0 replies; 4+ messages in thread From: Eric Biggers @ 2021-05-07 18:56 UTC (permalink / raw) To: Kestrel seventyfour; +Cc: linux-crypto On Fri, May 07, 2021 at 03:02:11PM +0200, Kestrel seventyfour wrote: > Hi Eric, > > I agree, that it can't be built on top of the kernels CBC. But in the > hardware CBC, e.g. for encryption I set the IV (encrypted tweak), set > the hardwares aes mode to CBC and start the encrypt of a 16 byte > block, then do an additional xor after that -> result of that full > block is the same as XTS. Then I gfmul the tweak and repeat the > previous starting with setting the tweak as iv. > Doing that is much faster and much more efficient than using the > kernels xts on top of ecb(aes). But it introduces the problem that I > have somehow to handle the CTS after my walk loop that just processes > full blocks or multiples of that. And I am trying to figure out, what > the best way is to do that with the least amount of code in my driver. > I cannot set blocksize to 1, because then the block size comparison to > generic xts fails and If I set the walksize to 1, I get the alignment > and split errors and would have to handle the splits and > missalignments manually. > So actually I need a combination of what the walk does (handle > alignment and splits) plus getting the last complete and incomplete > block after walk_skcipher_done returns -EINVAL. At least thats my > current idea. I could just copy most of the code from xts, but there > is a lot of stuff, that is not needed, if I combine the hardware CBC > and xor to be XEX (XTS without the cipher text stealing). > Wouldn't it be easier to just implement ecb(aes) in your driver (using your workaround to do it 1 block at a time using the hardware CBC engine)? If you implement ecb(aes), then the xts template can use it, so you wouldn't need to implement xts(aes) directly. And this would still avoid all the individual calls to crypto_cipher_{encrypt,decrypt}, which I expect is the performance bottleneck that you were seeing. - Eric ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-05-07 18:56 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-07 5:57 xts.c and block size inkonsistency? cannot pass generic driver comparision tests Kestrel seventyfour 2021-05-07 6:55 ` Eric Biggers [not found] ` <CAE9cyGTi9YpC9pcu5-MXtmXu_DM5FEVt9DYrM4AQWQMK7f0=zA@mail.gmail.com> 2021-05-07 13:02 ` Fwd: " Kestrel seventyfour 2021-05-07 18:56 ` Eric Biggers
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.