[Cryptography] WireGuard

Paul Wouters paul at cypherpunks.ca
Tue Sep 4 22:47:29 EDT 2018

On Mon, 3 Sep 2018, Ray Dillinger wrote:

> If I were designing something to have a five-year upgrade cycle, it
> would be the right choice to have a cipher currently believed secure,
> with key at least twice as long as "justified" for the task at hand
> given known attacks, absolutely minimal protocol, and no algorithm
> negotiation.  There's no way around key handling, but using a single
> algorithm and a single key length can keep it simple.  So you can at
> least reduce or eliminate the biggest known design security problems.

Still, 5 years from now you are juggling two versions, and 10 years from
now three versions. Similarly, we went from cbc to gcm to whatever is
next and you'll want people using that and be compatible.

It's easy to start from scratch with very few options. But politics and
backwards compatibility and tweaks to harden or support some corner use
case will sneak in again.

My biggest issues with WireGuard is that they didn't sit down and
thought about how to best replace IPsec. They thought only about the
remote access VPN use case, put something together that mostly dictates
parameters out-of-band and then claiming how much better/faster/stronger
they are compared to IPsec. But IKE/IPsec offers much more then just a
Remote Access VPN. I suspect they will see over the next 10 years that
if the expand beyond the simple remote access use case, that they need
to -add their own warts to support these. There is a reason we have ESP
and AH, tunnel mode and transport mode, IPCOMP, MOBIKE, various user
authentication methods, various NOTIFICATION payloads, etc etc. I'd love
if that would all go away, but it won't unless either I or someone else
is being prevented their IPsec use case.

And there has been a lot of misinformation. WireGuard first claimed
to be much faster then IPsec until I showed them their claims were
wrong and they adjusted it to 5% faster (which is believable because
they don't support tunnel vs transport mode so have a few less bytes to
encrypt). They still complain that IKE/IPsec is "noisy" and that was based
on their complete misunderstanding of the DPD/liveness protocol in IKE,
in addition to not having the real world experience of NAT routers and
their protoport mapping bugs you need to work around. etc etc. Advising
people on a Mac to run a Linux VM just to get WireGuard as your VPN
service is not a sane thing to advise.

People forget that neither the IKE or ESP protocols have been broken
(unlike TLS). SLOTH came close but random SPI's saved it. It's just cool
these days to hate IPsec. But it is still an excellent work horse.

That said, yes I look forward to killing AH and IPCOMP and nested
transforms and IKEv1 and heck, I'd even drop PSK support because people
refuse to use strong random PSKs. It would be a large cut of code.

Anyway, I wish them luck in making and keeping a simple and strong
remote access VPN implementation, and urge them to be friendlier in
their community so as to not end up as loved as the systemd crowd :)


More information about the cryptography mailing list