Re: [PATCH 4/8] crypto: skcipher - Add lskcipher

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Dec 05, 2023 at 04:41:12PM +0800, Herbert Xu wrote:
> On Thu, Sep 21, 2023 at 08:10:30PM -0700, Eric Biggers wrote:
> > 
> > Yes, wide-block modes such as Adiantum and HCTR2 require multiple passes over
> > the data.  As do SIV modes such as AES-GCM-SIV (though AES-GCM-SIV isn't yet
> > supported by the kernel, and it would be an "aead", not an "skcipher").
> 
> Right, AEAD algorithms have never supported incremental processing,
> as one of the first algorithms CCM required two-pass processing.
> 
> We could support incremental processing if we really wanted to.  It
> would require a model where the user passes the data to the API twice
> (or more if future algorithms requires so).  However, I see no
> pressing need for this so I'm happy with just marking such algorithms
> as unsupported with algif_skcipher for now.  There is also an
> alternative of adding an AEAD-like mode fo algif_skcipher for these
> algorithms but again I don't see the need to do this.
> 
> As such I'm going to add a field to indicate that adiantum and hctr2
> cannot be used by algif_skcipher.
> 

Note that 'cryptsetup benchmark' uses AF_ALG, and there are recommendations
floating around the internet to use it to benchmark the various algorithms that
can be used with dm-crypt, including Adiantum.  Perhaps it's a bit late to take
away support for algorithms that are already supported?  AFAICS, algif_skcipher
only splits up operations if userspace does something like write(8192) followed
by read(4096), i.e. reading less than it wrote.  Why not just make
algif_skcipher return an error in that case if the algorithm doesn't support it?

- Eric