[twitchyliquid64]

My concern is that 'built on modern crypto' and 'reviewed by cryptographers' amounts to 'rolled our own crypto'. IMHO history has shown us time and time again that this is a bad idea - we should use the protocols and ciphers that have stood the test of time. Building subnet using TLS was an architectural choice to avoid playing the role of cryptographer and inevitably getting it wrong.

[zx2c4]

What a bunch of senseless FUD.

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.

[1] https://noiseprotocol.org

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

[twitchyliquid64]

> What a bunch of senseless FUD.

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?

[freedomben]

Bonus points for being classy despite being attacked.

> What a bunch of senseless FUD

Is not a very courteous way to begin a rebuttal. Definitely makes it feel like an ad hominem.

[daxorid]

It builds on Noise, which is very highly regarded and reasonably well researched in crypto circles. Ironically (vis-a-vis your comment), it was designed largely to avoid the mistakes inherent in developers "rolling [their] own" crypto on TLS with poorly chosen stacks, ciphers, parameters, downgrade criteria, etc.

https://noiseprotocol.org/noise.html

[twitchyliquid64]

Guess you could say noise is pretty quiet xD

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