On Thu, 18 Jul 2019 at 17:51, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jul 18, 2019 at 03:43:28PM +0000, Pascal Van Leeuwen wrote: > > > > Hmmm ... so the generic CTS template would have to figure out whether it is wrapped > > around ECB, CBC, XTS or whatever and then adjust to that? > > That's not hard to do. Right now cts only supports cbc. IOW > if you pass it anything else it will refuse to instantiate. > > > For XTS, you have this additional curve ball being thrown in called the "tweak". > > For encryption, the underlying "xts" would need to be able to chain the tweak, > > from what I've seen of the source the implementation cannot do that. > > You simply use the underlying xts for the first n - 2 blocks and > do the last two by hand. > OK, so it appears the XTS ciphertext stealing algorithm does not include the peculiar reordering of the 2 final blocks, which means that the kernel's implementation of XTS already conforms to the spec for inputs that are a multiple of the block size. The reason I am not a fan of making any changes here is that there are no in-kernel users that require ciphertext stealing for XTS, nor is anyone aware of any reason why we should be adding it to the userland interface. So we are basically adding dead code so that we are theoretically compliant in a way that we will never exercise in practice. Note that for software algorithms such as the bit sliced NEON implementation of AES, which can only operate on 8 AES blocks at a time, doing the final 2 blocks sequentially is going to seriously impact performance. This means whatever wrapper we invent around xex() (or whatever we call it) should go out of its way to ensure that the common, non-CTS case does not regress in performance, and the special handling is only invoked when necessary (which will be never). -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
