> -----Original Message-----
> From: Ard Biesheuvel <[email protected]>
> Sent: Thursday, September 26, 2019 3:16 PM
> To: Pascal Van Leeuwen <[email protected]>
> Cc: Jason A. Donenfeld <[email protected]>; Linux Crypto Mailing List <linux-
> [email protected]>; linux-arm-kernel 
> <[email protected]>;
> Herbert Xu <[email protected]>; David Miller <[email protected]>; 
> Greg KH
> <[email protected]>; Linus Torvalds <[email protected]>; 
> Samuel
> Neves <[email protected]>; Dan Carpenter <[email protected]>; Arnd 
> Bergmann
> <[email protected]>; Eric Biggers <[email protected]>; Andy Lutomirski 
> <[email protected]>;
> Will Deacon <[email protected]>; Marc Zyngier <[email protected]>; Catalin Marinas
> <[email protected]>
> Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API
> 
> On Thu, 26 Sep 2019 at 15:06, Pascal Van Leeuwen
> <[email protected]> wrote:
> ...
> > >
> > > My preference would be to address this by permitting per-request keys
> > > in the AEAD layer. That way, we can instantiate the transform only
> > > once, and just invoke it with the appropriate key on the hot path (and
> > > avoid any per-keypair allocations)
> > >
> > This part I do not really understand. Why would you need to allocate a
> > new transform if you change the key? Why can't you just call setkey()
> > on the already allocated transform?
> >
> 
> Because the single transform will be shared between all users running
> on different CPUs etc, and so the key should not be part of the TFM
> state but of the request state.
> 
So you need a transform per user, such that each user can have his own
key. But you shouldn't need to reallocate it when the user changes his
key. I also don't see how the "different CPUs" is relevant here? I can
share a single key across multiple CPUs here just fine ...

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com

Reply via email to