On Tue, May 11, 2021 at 12:31:17PM -0700, Eric Biggers wrote: > > Well, the problem is that it isn't well defined what the cra_blocksize property > actually means. Depending on the algorithm, it can mean either the minimum > input size, the required alignment of the input size, the exact input size that > is required (in the case of block ciphers), or the input size that is required > by the algorithm's internal compression function (in the case of hashes). > > "xts" follows the convention of cra_blocksize meaning the "minimum input size", > as do "cts" and "adiantum" which have the same constraints on input sizes as > "xts". > > So I'm not sure that changing cra_blocksize for xts to 1 would accomplish > anything useful, other than confuse things further. At this point we can't change the blocksize of cts/xts to 1 without breaking af_alg because it needs to treat them differently than it would for a stream cipher like ctr. But to properly support af_alg on cts/xts we do need to do this. I have a patch-set that adds the final chunk size to do exactly that but I haven't had the time to finish it. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
