| Message ID | cover.1707815065.git.herbert@gondor.apana.org.au |
|---|---|
| Headers | show |
| Series | crypto: Add twopass lskcipher for adiantum | expand |
On Tue, Feb 13, 2024 at 05:04:25PM +0800, Herbert Xu wrote: > [PATCH 00/15] crypto: Add twopass lskcipher for adiantum 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 "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? Previously you had said you don't want shash being used alongside ahash. I'd prefer there was a clear plan before merging a bunch of patches that leave everything in a half-finished state. 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. > In addition to converting adiantum, the underlying chacha algorithm > is also converted over to lskcipher. > > The algorithms cts + xts have been converted too to ensure that the > tailsize mechanism works properly for them. While doing this the > parameters for cts + xts have been modified so that blocksize is now > 1. This entails changing the paramters of all drivers that support > cts and/or xts. cts and xts have nothing to do with adiantum. So this further indicates that the scope of this work is broader than just "crypto: Add twopass lskcipher for adiantum" as suggested by the title. It would be good to have a sense for the direction of this work. What will be coming next? - Eric
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@gondor.apana.org.au/ 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,
On Thu, Feb 15, 2024 at 04:20:34PM +0800, Herbert Xu wrote: > 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. What is the benefit of that change? This series also goes way beyond that, so it seems like there's more going on here. I do like the support for vaddr; the scatterlist-based APIs have always been one of the main pain points with the crypto API. But you're claiming that fixing that isn't actually the goal. So I'm confused. > > "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. dm-verity usually hashes 4K at a time, but that was enough for people to want it to support hardware accelerators, so it had to be switched to ahash. But, you objected to my patch that added shash support to dm-verity alongside ahash (https://lore.kernel.org/dm-devel/20231030023351.6041-1-ebiggers@kernel.org). That suggests that adding lskcipher support to dm-crypt and fscrypt alongside skcipher would similarly not be "allowed". Most users don't use off-CPU hardware accelerators with those, but some do. I did get away with (so far) switching fs/verity/ to shash. I'm not sure I could similarly get away with switching fs/crypto/ to lskcipher. There are people using the CAAM AES-CBC hardware accelerator with fscrypt. Before we go through a big effort to convert all these algorithms to lskcipher, or (more likely based on history) leave everything in a half-finished state, I'd like to get a good sense that lskcipher will be useful. - Eric