> -----Original Message----- > From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > Sent: Thursday, September 26, 2019 3:16 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Cc: Jason A. Donenfeld <Jason@xxxxxxxxx>; Linux Crypto Mailing List <linux- > crypto@xxxxxxxxxxxxxxx>; linux-arm-kernel <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>; > Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; David Miller <davem@xxxxxxxxxxxxx>; Greg KH > <gregkh@xxxxxxxxxxxxxxxxxxx>; Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>; Samuel > Neves <sneves@xxxxxxxxx>; Dan Carpenter <dan.carpenter@xxxxxxxxxx>; Arnd Bergmann > <arnd@xxxxxxxx>; Eric Biggers <ebiggers@xxxxxxxxxx>; Andy Lutomirski <luto@xxxxxxxxxx>; > Will Deacon <will@xxxxxxxxxx>; Marc Zyngier <maz@xxxxxxxxxx>; Catalin Marinas > <catalin.marinas@xxxxxxx> > Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API > > On Thu, 26 Sep 2019 at 15:06, Pascal Van Leeuwen > <pvanleeuwen@xxxxxxxxxxxxxx> 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
