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. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
