Related: Wireguard is a new VPN for linux in 4k lines of C https://www.wireguard.com/
the model of wireguard has been proven correct by formal methods. Builds on modern crypto, and they kept code short for auditing purposes.
the model of wireguard has been proven correct by formal methods. Builds on modern crypto, and they kept code short for auditing purposes.
> There is no group of users that should be using the code in this repository here under any circumstances at the moment, not even beta testers or dare devils.
Despite the warning I attempted to use it, but without any real docs I didn't get very far.
- https://www.wireguard.com/quickstart/
- https://www.wireguard.com/install/
- https://git.zx2c4.com/WireGuard/about/src/tools/wg.8
- https://git.zx2c4.com/WireGuard/about/src/tools/wg-quick.8
But I use a Mac so I can’t join the VPN I made :/
[1] Send a blank email to wireguard-join at lists dot zx2c4 dot com.
[2] https://lists.zx2c4.com/pipermail/wireguard/2017-May/001338....
WireGuard is based on the Noise Protocol Framework [1], designed by the same fella as the Signal Protocol, and already used in production by millions of devices all around the world inside of WhatsApp. Not only that, but we have a formal verification [2] that the crypto is correct in the symbolic model. The WireGuard paper itself [3] was presented to the academic community at NDSS [4]. It's most certainly not the hastily-made nonsense you imply it is with the phrase "rolled our own crypto".
Meanwhile your project, "subnet", tunnels TCP over TCP, which is well known for having pathologically bad performance characteristics [5]. 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 [6].
There's a lot of work that goes into doing tunneling well. I encourage your effort to make a fun toy project; it's a great learning opportunity. But please don't spread FUD about other projects without first understanding them.
[2] https://www.wireguard.com/formal-verification/
[3] https://www.wireguard.com/papers/wireguard.pdf
[4] https://www.ndss-symposium.org/ndss2017/
[5] https://www.google.com/search?q=tcp+over+tcp
[6] https://github.com/twitchyliquid64/subnet/blob/50fc8fe2b6ccf...
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?
> What a bunch of senseless FUD
Is not a very courteous way to begin a rebuttal. Definitely makes it feel like an ad hominem.
+1 for trying to eliminate complexity from developer error. This was one of the worst cows in the herd for OpenSSL.
That said, I think a bit of good design on the APIs part can go a long way. For Instance, I think Go's crypto/tls aint bad: Its pretty difficult to 'accidentally' configure it in a shocking configuration (suites have to be overridden, turning off verification requires you to set a field called InsecureNoVerify etc).