On Thu, 26 Sep 2019 at 16:03, Pascal Van Leeuwen
[off-list ref] wrote:

quoted

-----Original Message-----
From: Ard Biesheuvel <redacted>
Sent: Thursday, September 26, 2019 3:16 PM
To: Pascal Van Leeuwen <redacted>
Cc: Jason A. Donenfeld <Jason@zx2c4.com>; Linux Crypto Mailing List <linux-
crypto@vger.kernel.org>; linux-arm-kernel [off-list ref];
Herbert Xu [off-list ref]; David Miller [off-list ref]; Greg KH
[off-list ref]; Linus Torvalds [off-list ref]; Samuel
Neves [off-list ref]; Dan Carpenter [off-list ref]; Arnd Bergmann
[off-list ref]; Eric Biggers [off-list ref]; Andy Lutomirski [off-list ref];
Will Deacon [off-list ref]; Marc Zyngier [off-list ref]; Catalin Marinas
[off-list ref]
Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API

On Thu, 26 Sep 2019 at 15:06, Pascal Van Leeuwen
[off-list ref] wrote:
...

quoted

quoted

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 ...

We need two transforms per connection, one for each direction. That is
how I currently implemented it, and it seems to me that, if
allocating/freeing those on the same path as where the keypair object
itself is allocated is too costly, I wonder why allocating the keypair
object itself is fine.

But what I am suggesting is to use a single TFM which gets shared by
all the connections, where the key for each operation is provided
per-request. That TFM cannot have a key set, because each user may use
a different key.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel