On Fri, 5 Jul 2019 at 05:08, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jul 04, 2019 at 08:11:46PM +0200, Ard Biesheuvel wrote: > > > > To be clear, making the cipher API internal only is something that I > > am proposing but hasn't been widely discussed yet. So if you make a > > good argument why it is a terrible idea, I'm sure it will be taken > > into account. > > > > The main issue is that the cipher API is suboptimal if you process > > many blocks in sequence, since SIMD implementations will not be able > > to amortize the cost of kernel_fpu_begin()/end(). This is something > > that we might be able to fix in other ways (and a SIMD get/put > > interface has already been proposed which looks suitable for this as > > well) but that would still involve an API change for something that > > isn't the correct abstraction in the first place in many cases. (There > > are multiple implementations of ccm(aes) using cipher_encrypt_one() in > > a loop, for instance, and these are not able to benefit from, e.g, > > the accelerated implementation that I created for arm64, since it open > > codes the CCM operations) > > I agree with what you guys have concluded so far. But I do have > something I want to say about eboiv's implementation itself. > > AFAICS this is using the same key as the actual data. So why > don't you combine it with the actual data when encrypting/decrypting? > > That is, add a block at the front of the actual data containing > the little-endian byte offset and then use an IV of zero. > That would only work for encryption. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
