Re: [PATCH 00/15] crypto: Add twopass lskcipher for adiantum

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux