The real competitor, which the article doesn't talk about is https://www.zerotier.com/ . Is is also open-source and have been available on macOS, iPhone, Android, Windows on top of Linux for many months now. It is easy to install and use. Deals with punching NAT and does smart routing when both devices are on the same network.
I don't know how well it compares in terms of performance and crypto, it would be nice to know.
Where is ZeroTier's protocol documented? All I could find was a document that said it was custom, and "like IPSEC". What could ZeroTier do as a VPN protocol that would make it better than WireGuard, which has a pedigreed protocol that, in its WireGuard incarnation, has had multiple rounds of formal validation?
I wrote the article we're commenting on. Why would I take the time to talk about something like ZeroTier? WireGuard solves the problem I'm talking about decisively.
I'm prepared to hear something about ZeroTier that makes it interesting in the WireGuard setting, but I am not interested in a long list of non-VPN non-access-tunnel features that ZeroTier might have that WireGuard lacks, because lacking random features is exactly the point of WireGuard.
ZeroTier solves a broader set of problems than WireGuard and has SDN-type network flow rules, security tap capability, and is a full L2 emulation layer with support for multicast.
From what I've seen the WireGuard protocols are excellent and the implementation is very nice and clean. A core ZeroTier implementation to support a simple L3 VPN use case could be as short as WireGuard but that would be without all the rules engine, multicast, etc. stuff.
Just the .cpp code, not counting the .hpp code (which is full of code, including lots of memcpy's) in the node/ subdirectory of this repo is something like 4x the entire size of Linux WireGuard. The crypto protocol is undocumented, but the maintainer is playing games with things like the Salsa round count (which is fine, but I mean, speaks to a mindset). I might poke at it for sport at some point, but I don't see how I could ever recommend it.
A minimal implementation could be much shorter, but the ref implementation is not minimal and includes a lot of features that go far beyond the scope of WireGuard.
Salsa20/12 is standard and according to the docs is considered secure. I recall that DJB initially specified the cipher with 12 rounds but added 8 more for margin. There are Salsa20/12 implementations in many crypto libraries. The best public cryptanalysis on Salsa breaks 8/20 rounds with a time difficulty of 2^251.
Personally I think concern over algorithm strength is usually misplaced as long as you're using an algorithm that is not known to be very weak (e.g. DES, RC4). Halfway decent cryptographic algorithms are almost never broken. Implementations and protocols are broken all the time.
One thing we did to guard against protocol issues was to implement what DJB calls "boring crypto." The cryptographic encapsulation is dirt simple Salsa20+Poly1305 constructed exactly as in the NaCl secret box functions, and nothing more. We've resisted adding more advanced features to the cryptographic layer because so far they haven't really been necessary and the risk is not worth the small benefit they may have.
At the time this was designed (started in 2010) Salsa20/12 was the best option to achieve high performance across a variety of devices including ARM phones and slow VMs with a clean and small code base. If it were written today it would probably use ChaCha20 (faster) or AES-GCM since almost everything worth mentioning has hardware AES now. We will likely rev the crypto at some point but would also like to upgrade the asymmetric cipher as well. Waiting to see if the Goldilocks curves (curve448) get added to the NIST standard. They are proposed but not yet approved. If they are we'd probably go to curve448+AES256-GCM with a longer IV.
That being said we're not solely oriented toward crypto and generally tell our users not to rely on network crypto as their only line of defense. Network crypto is sort of analogous to hard drive encryption. It protects you from people who don't have access to anything, but won't save you once someone gets any access beyond the perimeter. We advocate the use of encryption and authentication within networks as well if you care about security. This also guards against the discovery of a bug in any layer-- if someone breaks one layer they are confronted by another layer.
An RFC-style write-up has been on the to-do list forever, but the to-do list is very long.
I've been poking around for about 30 minutes and I'm still not sure I understand what the key agreement protocol is. I'm trying to follow starting from _doHELLO and you're losing me somewhere amidst the moons and worlds and stuff.
An identity is a public key. An address is a hash of that public key. Key agreement is just SHA512(Curve25519(my secret + your public)). Public keys are looked up from addresses via "upstream" nodes by the sender. An upstream node is typically one of our root servers unless someone has added their own.
Crypto here is fairly dirt simple as I said. It's just ECDH with two Curve25519 keys and then go.
The moons/worlds stuff is just some odd terminology for how to define upstream nodes. We are dumping that in favor of something more straightforward in the future. Most users don't need to care about it.
I'd like to avoid GCM but we also may have a need for FIPS compliance in the future. Yes I know that FIPS basically mandates weaker crypto... or at least crypto that is easier to implement wrong... but if it's not FIPS it isn't "enterprise" to some (clueless) people. Then you have organizations mandated to use FIPS crypto by forces beyond their control.
Not in 1.2. This is planned for 1.4. It's fairly prominent in the manual.
It was left out of the original design since ephemeral negotiation means state and therefore latency and stalls if packets are dropped. The present design leaves it out as part of a design that prioritizes instantaneous connectivity.
When we do add it we will probably add a network level config option to select whether forward secrecy is required. If it's off it will work instantly and then lazily upgrade. If this option is on it will wait.
As I said though I don't see network level (L2/L3) encryption as being worth much more than whole disk encryption. Each really secure thing should have it's own secure authenticated session that would be secure enough over the open Internet. That way a network compromise or trojan is not instantly fatal. We pretty much tell everyone this.
Have you considered just, you know, adopting the WireGuard protocol and then building something on top of it to coordinate connections?
I built something like this (in C++, no less!) back in 2000. After the company failed, I always felt like we had made a mistake not just shipping the absolute simplest possible message forwarder, and then implementing the control plane for it in a reasonable high-level language. (In fact: an early team member pushed us to do that, and I shot them down.)
Yes I have considered that. It didn't exist in 2010 so it's worth taking a look. It already does some of what we want, but the devil is in the details.
Noise also did not exist in 2010. The cryptographic world is so much richer today than it was even 8 years ago. When I think back to the crypto dark ages I shudder.
This may come off as rude ... but tptacek there is a fine line between being enthusiastic and aggressively dickish. All over this thread you have been PUSHING hard... way harder than you should have to if your product is as good as you are touting. It's one thing to promote, but what I've read all over this post (not just this thread) is someone whose personality REFUSES to allow them to even give a small inch in a debate -- feels a drive to be right no matter the cost. That makes me question how likely you are to take input from people who can / want to help ...
Friendly advice -- roll yourself back down to an 8 or 9.
WireGuard isn't "my" project. I have no formal relationship with the developer, other than that we like his work so much we've contributed a bit to its development (less than others).
You're not being rude. But I have no plans to give an inch on this discussion. If that's problematic for you, you're welcome to use the HN votey-buttons as you see fit.
Just letting you know that your comments/attitude/etc are likely hurting the cause you are championing. Your volume of replies, the tone you take in them, and the way you react makes it seem like you ARE deeply part of the project... Thus I (and likely many others) associate you with it. I don't care what you comment - be a dick to the fullest if that's your thing - I was simply letting you know the impression you are leaving out there.
It may not be interesting to you. To me, and probably a lot of people, the ability to communicate directly between two hosts each behind a NAT (using UDP hole punching) is a big advantage for a VPN, since, compared to forwarding through a central server, it can be faster and lower latency, and it also means you don’t have to pay for that server.
Edit: As to why it’s relevant to the “WireGuard setting”, that depends on your definition of the WireGuard setting, but: (1) it’s easy to find examples of people trying to use WireGuard for peer-to-peer communication, the use case ZeroTier solves better; and (2) ZeroTier shares WireGuard’s property of being stateless/connectionless, a significant convenience advantage over traditional VPN protocols.
I think I could have worded that better. By "in the WireGuard setting" I mean "doing the job most startups will use WireGuard to do", which is, manage remote access to internal resources in the cloud.
I don't think overlay networks are pointless; I am enthusiastic about them. But for the remote access problem, what I want and what I'm writing about is streamlined VPN software, not a new overlay.
Fair enough, although… you know more about this use case than me, but wouldn’t you generally have a large number of servers in the cloud you want to provide remote access to? So if you’re using WireGuard, either you have to configure each client to talk to each server it needs access to – which could be good for security, but sounds like a pain to set up – or you have a central server that serves as a hub for all the VPN traffic. In your blog post you said you just had to “point the client at the server”, so I’m guessing you’re envisioning the latter. But then wouldn’t an overlay network work better in many cases? For example, if you have cloud servers in different geographical locations, and as the developer you’re near one of those locations but far from the VPN server, you’d have lower latency connecting directly…
I'm imagining simply replacing OpenVPN servers with WireGuard servers, retaining the VPN gateway model; one WireGuard instance acts as a routing gateway for any number of servers.
The only real complaint I would have over WireGuard is that with zerotier, I only need to connect to one server and then can talk to any servers on the same "network" as long as the acl permits it. The other servers are discovered automatically.
With WireGuard, I'm pretty sure I would have to set up multiple peers and custom routes. Although I'm assuming you could run BGP on top of the wg interface and that would solve some of it.
That said, I'd much rather something the simplicity of wireguard or tinc because it doesn't require a server who's only purpose is to manage clients.
I know it's not specifically related to the protocol either uses, but I think people would consider that as a drawback when comparing the two. If you're coming from openvpn/ipsec, then setting up any sort of mesh/routed network would be a similar process. I don't think wireguard would need to implement functionality like that either, I think it would be better if something like tinc used wireguard for the plumbing as someone else mentioned in the comments.
I don't know how well it compares in terms of performance and crypto, it would be nice to know.