On Wed, Feb 14, 2024 at 03:35:17PM -0800, Eric Biggers wrote: > > Thanks. Can you include an explanation of the high-level context and goals for > this work? It's still not clear to me. I'm guessing that the main goal is to > get rid of the vaddr => scatterlist => vaddr round trip for software > encryption/decryption, which hopefully will improve performance and make the API > easier to use? And to do that, all software algorithms need to be converted to The main goal is to remove the legacy cipher type, and replacing it with lskcipher. The vaddr interface is simply a bonus. In fact this particular series is basically my response to your questions about adiantum from that thread: https://lore.kernel.org/linux-crypto/20230914082828.895403-1-herbert@xxxxxxxxxxxxxxxxxxx/ But yes I will update the cover letter. > "lskcipher"? Will skcipher API users actually be able to convert to lskcipher, > or will they be blocked by people expecting to be able to use hardware crypto > accelerators? Would you accept lskcipher being used alongside skcipher? That's a question for each user to decide. > Previously you had said you don't want shash being used alongside ahash. In general, if the amount of data being processed is large, then I would expect the use of hardware accelerators to be a possibility and therefore choose the SG-based interface. I wouldn't consider 4K to be large though. So it's really when you feed hundreds of kilobytes of data through the algorithm when I would recommend against using shash. > By the way, note that hctr2 requires two passes too, as it's an SPRP like > Adiantum. Also note that SPRPs in general may require more than two passes, > though Adiantum and HCTR2 were designed to only need two (technically they have > three passes, but two are combinable). It's fine to support only two passes if > that's what's needed now; I just thought I'd mention that there's no guarantee > that two passes will be enough forever. Right, there is no reason why we couldn't extend this to more than two passes when the need arises. The CCM algorithm could also be implemented in this manner with three passes (although the first pass is a bit of a waste since it simply tallies up the length of the input). Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
