Received-SPF: pass (google.com: domain of linux-crypto+bounces-143-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu, 16 Nov 2023 21:42:31 -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>,
	Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH 4/8] crypto: skcipher - Add lskcipher
Message-ID: <20231117054231.GC972@sol.localdomain>
References: <20230914082828.895403-1-herbert@gondor.apana.org.au>
 <20230914082828.895403-5-herbert@gondor.apana.org.au>
 <20230920062551.GB2739@sol.localdomain>
 <ZQvHUc9rd4ud2NCB@gondor.apana.org.au>
 <20230922031030.GB935@sol.localdomain>
 <ZVb38sHNJYJ9x0po@gondor.apana.org.au>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZVb38sHNJYJ9x0po@gondor.apana.org.au>

On Fri, Nov 17, 2023 at 01:19:46PM +0800, Herbert Xu wrote:
> On Thu, Sep 21, 2023 at 08:10:30PM -0700, Eric Biggers wrote:
> >
> > Well, IV is *initialization vector*: a value that the algorithm uses as input.
> > It shouldn't be overloaded to represent some internal intermediate state.  We
> > already made this mistake with the iv vs. iv_out thing, which only ever got
> > implemented by CBC and CTR, and people repeatedly get confused by.  So we know
> > it technically works for those two algorithms, but not anything else.
> > 
> > With ChaCha, for example, it makes more sense to use 16-word state matrix as the
> > intermediate state instead of the 4-word "IV".  (See chacha_crypt().)
> > Especially for XChaCha, so that the HChaCha step doesn't need to be repeated.
> 
> Fair enough, but what's the point of keeping the internal state
> across two lskcipher calls? The whole point of lskcipher is that the
> input is linear and can be processed in one go.
> 
> With shash we must keep the internal state because the API operates
> on the update/final model so we need multiple suboperations to finish
> each hashing operation.
> 
> With ciphers we haven't traditionally done it that way.  Are you
> thinking of extending lskcipher so that it is more like hashing, with
> an explicit finalisation step?

crypto_lskcipher_crypt_sg() assumes that a single en/decryption operation can be
broken up into multiple ones.  I think you're arguing that since there's no
"init" or "final", these sub-en/decryptions aren't analogous to "update" but
rather are full en/decryptions that happen to combine to create the larger one.
So sure, looking at it that way, the input/output IV does make sense, though it
does mean that we end up with the confusing "output IV" terminology as well as
having to repeat any setup code, e.g. HChaCha, that some algorithms have.

- Eric