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. > > > > It all depends on whether we are interested in supporting async > > accelerators or not, and it is clear what my position is on this > > point. > > > Maybe not for an initial upstream, but it should be a longer-term goal. > > > > > What I *don't* want is to merge WireGuard with its own library based > > crypto now, and extend that later for async accelerators once people > > realize that we really do need that as well. > > > What's wrong with a step-by-step approach though? i.e. merge it with > library calls now and then gradually work towards the goal of integrating > (a tweaked version of) the Crypto API where that actually makes sense? > Rome wasn't built in one day either ... > I should clarify: what I don't want is two frameworks in the kernel for doing async crypto, the existing one plus a new library-based one.
