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
