For anyone that thought this doesn't feel comprehensive the Prior Work sections covers why -

"The WireGuard handshake protocol has undergone rigorous formal verification of desired properties using the Tamarin proof system [2]. Many of the cryptographic primitive implementations have also been formally verified as correct. The remaining implementations have been carefully fuzzed against the verified implementations to ensure correctness."

So all put together the simplicity goal really paid off for WireGuard.

Less code = Less surface area for attack?

Not just that, less code (and simple code) = much easier to prove that the code is correct.

Please just say 'correct'.

Also, Kenny Paterson's analysis:

https://eprint.iacr.org/2018/080

And, of course, the original peer-reviewed NDSS paper:

https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/...

Spoiler: it's pretty solid.

Boring in the sense that nothing exciting was found,but encouraging that 1) nothing was found! 2) null-result publication is useful in and of itself, sometimes.

There was a finding! A very very minor bug in the keepalive timer's rounding.

I mean, it's something.

Was that the reference to the 80% packet loss between two networks?

The packet loss and artificial latency were what the authors refer to as fuzzing.

The packet loss was artificial to test resiliency.

> 2) null-result publication is useful in and of itself, sometimes.

I want to believe, but try getting a null result peer reviewed.

Ultimately this is a fatal flaw in the peer review system in the way most scientific publications do it.

The review should happen independent of the result and ideally the publication decision should happen before the research is performed. (There are some publications that do something alike - it's called "Registered Reports" - but it's still a small minority.)

How much of a challenge is it to implement a purely userspace client? Last I checked the wireguard app depends on the Linux kernel's Crypto primitive API's a lot.

For increased adoption,it needs to support windows and iOS.

Not only that, high performance packet routing is sometimes done mostly in user-space (haven't looked much into XDP yet).

They're in the works.

https://git.zx2c4.com/

iOS is not compatible with GPL license and that platform is horribly closed and people shouldn't use it for anything more serious than DRM content consumption. I tried to compile it with dev provisioning profile but gave up in the end, it is also not complete yet. It works perfectly and easily on Android and Linux and that's what I care about the most.

I gave up on getting Wireguard to work on an Arch server and an Android client. Algo only supports Ubuntu and *BSD.

> Algo only supports Ubuntu and *BSD.

Algo, also called Algo VPN, is a separate project which is built on-top of Wireguard [0]. Algo claims to support Android [1].

Wireguard works on Arch and Android [2]. Wireguard for Arch has first class support [3]. Wireguard for Android exists in a forked repository [4].

[0] https://github.com/trailofbits/algo

[1] https://github.com/trailofbits/algo/blob/master/docs/client-...

[2] https://www.wireguard.com/install/

[3] https://wiki.archlinux.org/index.php/WireGuard

[4] https://git.zx2c4.com/wireguard-android

I use it on Arch with no issues at all.

Same. I've also set up WireGuard on Ububtu servers and the experience was pretty much identical. Arch doesn't make this any harder.

Works fine for me on Manjaro using wireguard-dkms and the Wireguard app from the F-Droid store.

Copying public keys back and forth via email seemed a bit of a faff so there's probably a better way. Possibly using `qrencode` would let you set up the client configuration...

Perhaps I am misunderstanding the premise of Wireguard as all the tutorials seem to be setting up a client and a server that are on the same network, is not possible to have the server as a VPS and have the client connect via the Internet?

It is really no difference between setting up Wireguard on a local network or via Internet as long as one of the hosts can listen to a public UDP port. If one of your clients are behind a NAT you may need to enable the keep alive option in the client's config

Sadly some public networks I had to use were blocking Wireguard, while my IPSec VPN would easily go through each time :(

I wish there was an option to obfuscate the traffic as a plain HTTPS connection, but that would defeat the idea of keeping Wireguard simple.

My client is indeed behind a NAT. I'll just wait until Wireguard is more mainstream and extremely detailed guides are up.

Admittedly, I haven't gotten around to actually using WireGuard yet, but I think it's pretty much as simple as Linuskendall said. https://www.wireguard.com/quickstart/#nat-and-firewall-trave...

Also see this guide on using a public VPS with a Wireguard server to share resources behind two different NAT'd networks: https://staaldraad.github.io/2017/04/17/nat-to-nat-with-wire...