MIME-Version: 1.0
References: <ZAw2eHDQELdiVXcZ@gondor.apana.org.au> <CAMj1kXGC81=z_h-gcdQ0OoNA01kSAJz58QNiB1ixCPFA0_YnUw@mail.gmail.com>
 <ZAw5Ffv7X2mNmbG8@gondor.apana.org.au> <CAMj1kXEr8W1NP0Xcny7ed1xb7ofb7Y6R57TPNe6=jAASDzHzKw@mail.gmail.com>
 <ZAxAK2rlOsQjlgB9@gondor.apana.org.au> <CAMj1kXG_27v0YXoO_8Avjcz=YtYhCfX_6pcXowk0fy5cYR6gVw@mail.gmail.com>
 <ZAxDOhfuSTsgncMU@gondor.apana.org.au> <CAMj1kXHdNZ-=3-VuerRVWiRYixFf8KoeFk54Gz=09aV9Wwtdsg@mail.gmail.com>
 <ZAxIKu3t4NJEGz6I@gondor.apana.org.au> <CAMj1kXF6_JFMFTqzmXWxM=zJ7HmDqnivAKjUT=pN-34werkd5g@mail.gmail.com>
 <ZAxM5NLU6a2SUDuh@gondor.apana.org.au>
In-Reply-To: <ZAxM5NLU6a2SUDuh@gondor.apana.org.au>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Sun, 12 Mar 2023 09:06:45 +0100
Message-ID: <CAMj1kXG0eQ4fTxwadg5tqsm_Jw-cM4GL6CBpWc=N7hhj-deK1g@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 Sat, 11 Mar 2023 at 10:42, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Sat, Mar 11, 2023 at 10:25:48AM +0100, Ard Biesheuvel wrote:
> >
> > So what use case is the driver for this sync skcipher change? And how
>
> The main reason I wanted to do this is because I'd like to get
> rid of crypto_cipher.  I'm planning on replacing the underlying
> simple ciphers with their ECB equivalent.
>
> > will this work with existing templates? Do they all have to implement
> > two flavors now?
>
> Let's say we're calling this vkcipher.  Because the existing
> skcipher templates should continue to work with an underlying
> vkcipher algorithm, I won't be adding any vkcipher template
> unless there is a specific use-case, such as CFB here.
>
> But I will do the common ones like CBC/CTR.
>

Interesting. So I think having an interface like this would be useful.

However, to answer your original question, I don't think it makes
sense for James's stuff to be gated on this. In fact, I think
communication with the TPM should have as few moving parts as
possible, given how disruptive it might be if it fails, so I'd suggest
we merge this code in any case, and stick to simple library interfaces
where we can.