Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
MIME-Version: 1.0
References: <20230914082828.895403-1-herbert@gondor.apana.org.au>
 <CAMj1kXHLZ8kZWL3npQRavdzjRtv_uiRKmKDeXaQhhy3m4LvK+w@mail.gmail.com>
 <ZQLK0injXi7K3X1b@gondor.apana.org.au> <CAMj1kXHvhrUyShdSNCJeOh8WVXFqPPu+KLh16V6fJJdQKhPv1A@mail.gmail.com>
 <ZQLSlqJs///qoGCY@gondor.apana.org.au>
In-Reply-To: <ZQLSlqJs///qoGCY@gondor.apana.org.au>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Thu, 14 Sep 2023 11:31:14 +0200
Message-ID: <CAMj1kXE6mo2F7KgGmpygEs5cHf=mvUs2k3TT-xJ1wKP_YNGzFg@mail.gmail.com>
Subject: Re: [PATCH 0/8] crypto: Add lskcipher API type
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, 14 Sept 2023 at 11:30, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Sep 14, 2023 at 11:18:00AM +0200, Ard Biesheuvel wrote:
> >
> > So this means that the base name will be aes, not ecb(aes), right?
> > What about cbc and ctr? It makes sense for a single lskcipher to
> > implement all three of those at least, so that algorithms like XTS and
> > GCM can be implemented cheaply using generic templates, without the
> > need to call into the lskcipher for each block of input.
>
> You can certainly implement all three with arch-specific code
> but I didn't think there was a need to do this for the generic
> version.
>

Fair enough. So what should such an arch version implement?

aes
cbc(aes)
ctr(aes)

or

ecb(aes)
cbc(aes)
ctr(aes)

?