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.

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.

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.

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.)

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.

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.