Re: [PATCH 13/15] crypto: cts,xts - Update parameters blocksize/chunksize/tailsize

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Feb 15, 2024 at 03:57:38PM +0800, Herbert Xu wrote:
> On Wed, Feb 14, 2024 at 03:00:21PM -0800, Eric Biggers wrote:
> >
> > Before messing around with cra_blocksize, it needs to be decided what it
> > actually means, and document it appropriately.  According to the current
> > specification, AES_BLOCK_SIZE is correct here, not 1:
> 
> Block size should always be set to 1 unless the algorithm is only
> capable of handling input data that is a multiple of block size.
> 
> >  * @cra_blocksize: Minimum block size of this transformation. The size in bytes
> >  *		   of the smallest possible unit which can be transformed with
> >  *		   this algorithm. The users must respect this value.
> >  *		   In case of HASH transformation, it is possible for a smaller
> >  *		   block than @cra_blocksize to be passed to the crypto API for
> >  *		   transformation, in case of any other transformation type, an
> >  * 		   error will be returned upon any attempt to transform smaller
> >  *		   than @cra_blocksize chunks.
> 
> OK this is wrong.  We should fix it.  For skciphers, the input
> length must be a multiple of blocksize.

That seems logical, but everything needs to be updated to be consistent.  Note
that adiantum and hctr2 also use the currently documented convention, i.e. they
support byte-aligned messages but they set cra_blocksize to 16 because that's
their minimum message size.  Also, while the proposed definition seems logical,
do you have any more specific rationale for wanting to make this change?

- Eric