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