WireGuard to port to existing Crypto API

[Jason A. Donenfeld]

Hi folks,

I'm at the Kernel Recipes conference now and got a chance to talk with
DaveM a bit about WireGuard upstreaming. His viewpoint has recently
solidified: in order to go upstream, WireGuard must port to the
existing crypto API, and handle the Zinc project separately. As DaveM
is the upstream network tree maintainer, his opinion is quite
instructive.

I've long resisted the idea of porting to the existing crypto API,
because I think there are serious problems with it, in terms of
primitives, API, performance, and overall safety. I didn't want to
ship WireGuard in a form that I thought was sub-optimal from a
security perspective, since WireGuard is a security-focused project.

But it seems like with or without us, WireGuard will get ported to the
existing crypto API. So it's probably better that we just fully
embrace it, and afterwards work evolutionarily to get Zinc into Linux
piecemeal. I've ported WireGuard already several times as a PoC to the
API and have a decent idea of the ways it can go wrong and generally
how to do it in the least-bad way.

I realize this kind of compromise might come as a disappointment for
some folks. But it's probably better that as a project we remain
intimately involved with our Linux kernel users and the security of
the implementation, rather than slinking away in protest because we
couldn't get it all in at once. So we'll work with upstream, port to
the crypto API, and get the process moving again. We'll pick up the
Zinc work after that's done.

I also understand there might be interested folks out there who enjoy
working with the crypto API quite a bit and would be happy to work on
the WireGuard port. Please do get in touch if you'd like to
collaborate.

Jason