MIME-Version: 1.0
References: <20230217144348.1537615-1-ardb@kernel.org> <Y/L6rSGDidhhWq2v@gondor.apana.org.au>
In-Reply-To: <Y/L6rSGDidhhWq2v@gondor.apana.org.au>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Mon, 20 Feb 2023 08:28:05 +0100
Message-ID: <CAMj1kXE8ZjVh=hLVgnRGr8cJpkqzRHsVxuq3dm1P=Aqc1QpcXg@mail.gmail.com>
Subject: Re: [PATCH v2] crypto: lib - implement library version of AES in CFB mode
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     linux-crypto@vger.kernel.org, ebiggers@kernel.org,
        James Bottomley <James.Bottomley@hansenpartnership.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, 20 Feb 2023 at 05:44, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Fri, Feb 17, 2023 at 03:43:48PM +0100, Ard Biesheuvel wrote:
> > Implement AES in CFB mode using the existing, mostly constant-time
> > generic AES library implementation. This will be used by the TPM code
> > to encrypt communications with TPM hardware, which is often a discrete
> > component connected using sniffable wires or traces.
> >
> > While a CFB template does exist, using a skcipher is a major pain for
> > non-performance critical synchronous crypto where the algorithm is known
> > at compile time and the data is in contiguous buffers with valid kernel
> > virtual addresses.
> >
> > Tested-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> > Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> > Link: https://lore.kernel.org/all/20230216201410.15010-1-James.Bottomley@HansenPartnership.com/
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> > v1 was sent out by James and is archived at the URL above
> >
> > v2:
> > - add test cases and kerneldoc comments
> > - add memzero_explicit() calls to wipe the keystream buffers
> > - add module exports
> > - add James's Tb/Rb
> >
> >  include/crypto/aes.h |   5 +
> >  lib/crypto/Kconfig   |   5 +
> >  lib/crypto/Makefile  |   3 +
> >  lib/crypto/aescfb.c  | 257 ++++++++++++++++++++
> >  4 files changed, 270 insertions(+)
>
> Could we remove the crypto/cfb.c implementation after this work
> is complete?
>

We would still not have any in-tree users of cfb(aes) or any other
cfb(*), so in that sense, yes.

However, skciphers can be called from user space, and we also rely on
this template for the extended testing of the various cfb() hardware
implementations that we have in the tree.

So the answer is no, I suppose. I would like to simplify it a bit,
though - it is a bit more complicated than it needs to be.