inb4 strawman arguments and other funzies.

Perhaps you should argue with me on my actual assertion, which is that 'we should use crypto that has stood the test and scrutiny of time'. Do not interpret my criticism as a personal attack.

> already used in production by millions of devices all around the world inside of WhatsApp.

Cool. This is good because that means we have a lot of eyes looking at it.

> formal verification that the crypto is correct in the symbolic model.

This is great and we need more of this kind of work. I don't think its good enough however; most practical attacks rely on side channels, implementation mistakes (formal verification helps in catching these but don't get you all the way), and other obscurities. I stand by my assertion that we should use crypto that has stood the test of time.

> The WireGuard paper itself [3] was presented to the academic community at NDSS

Congrats I guess? relevance?

> not the hastily-made nonsense you imply it is with the phrase "rolled our own crypto"

I made no such implication. 'Roll your own crypto' is a common phrase (at least in my circles) meaning to do it yourself instead of depend on someone else's implementation. Again, I don't see what this has to do with my assertion to use old and battle tested crypto.

> "subnet", tunnels TCP over TCP, which is well known for having pathologically bad performance characteristics

Correct, have a gold star. What does this have to do with crypto?

As you could tell if you scrolled down and read the other discussions around TCP-in-TCP, I am fully aware of the implication of my design decision, and stand by it is the right balance of simplicity, security, and speed (well, thats relative, but for what I was intending it for).

> It also has no binding between certificates and the IP addresses that a certificate is allowed to be inside the tunnel, and, unless I've misread, it allows different peers to hijack each others' IP addresses simply by asking

Correct, I am making the assumption that if posess a private key and cert minted by the server you are trusted. This could be fixed at the cost of additional complexity, loosing the ability for a client to change his address, and less alcohol-time on the developers part. That said, if someone asked me to network together hostile entities, I would have given him some coolaid instead of Go code. But I'm digressing, lets get back on topic.

> But please don't spread FUD about other projects without first understanding them.

I have done no such thing. I stand by my assertion that we should use Crypto that has stood the test of time. Am I not allowed to raise such assertions and discuss them on merit?