Received-SPF: pass (google.com: domain of linux-crypto+bounces-2266-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 22 Feb 2024 22:09:14 -0800
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH 13/15] crypto: cts,xts - Update parameters
 blocksize/chunksize/tailsize
Message-ID: <20240223060914.GH25631@sol.localdomain>
References: <cover.1707815065.git.herbert@gondor.apana.org.au>
 <b149e8743355be694c96da02ced0811963298373.1707815065.git.herbert@gondor.apana.org.au>
 <20240214230021.GC1638@sol.localdomain>
 <Zc3D8kwfZXiCagOL@gondor.apana.org.au>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zc3D8kwfZXiCagOL@gondor.apana.org.au>

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