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

Thanks for the suggestions, but decreasing the ping interval only made the VPN fail faster, and there was no difference in behavior between ping-restart and ping-exit :-(.

Explosion of interest in machine learning and data science and decent Python-based tools for those fields.

They followed up on that question with another blog post: https://stackoverflow.blog/2017/09/14/python-growing-quickly...

Python's huge popularity in scientific computing fields along with it being widely taught in schools. Notice also that R was on the list, which is obviously due to huge uptick in data science. R has been around for awhile as well.

> 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?

I don't think the comparison to Wireguard is apples-to-apples. Wireguard implements it's own semi-custom cryptosystem (Noise) whereas subnet rides on top of Go standard TLS implementation. So depending on how you view things, Wireguard is either much simpler (if you compare to the whole TLS stack) or much more complex (if you assume Go TLS to be reliable/trustworthy)

Maybe I misunderstood your comment, but WireGuard is less than 4k LoC, which is a few orders of magnitude smaller than OpenVPN or IPsec.

The Go implementation is not done yet! But it will be soon. In the meantime, feel free to use the Linux kernel implementation, which works quite well and has extensive documentation and man pages:

- https://www.wireguard.com/

- 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

I have been using Go for about 4 years at work and I would say they have been unlucky with the code they have looked at. You have the freedom to organize your code as you wish, you can easily go from one extreme to the other, one function per file to 1000 in one file. The only thing that isn't encouraged is to have very small packages, for example, if your project ends up split into 10 packages, but each of them is just one file (or one code file plus a test file), then most Go developers would suggest to group more files into a single package.

I've only dabbled myself, but I can see how that would start; I come from a Java background which forces you to have one module / class per file, but Go doesn't. It's very easy to start hacking up a thing, and it's easier in development to just keep it in one file. Of course, the nature of code is that it grows, so spend enough time there and it'll start growing. If you're familiar with the code (as in, you wrote it yourself), single files shouldn't be a problem.

It's not uncommon in other projects either, NodeJS for example has a relatively small number of large files (https://github.com/nodejs/node/blob/master/src/node.cc).

Go definitely prefers modular fashion. But definitely no gratuitous files/packages structure like Java where a dozen packages each with 2-3 files having nothing more than 50 lines of code out of which 30 are comments and imports of another dozen packages.

Unlike Java, Go does not have limitation of having each public class in its own file. So public symbols of any type can be put together in same file if it makes sense. Go prefers arranging code what makes sense for application functionality instead of auto-generated scaffolding like 'handlers', 'utils', 'assets', 'entities' etc like I do in my Java code.

Most of Go code I was working on or contributed to usually has quite a split out structure and more complex structs are defined in multiple files with related methods grouped together. I have seen couple of Go packages which consist of one huge file but I think it's quite rare. Most people will structure their code into multiple files to keep it more readable/maintainable and file sizes relatively small.

I don't see any reason why Go would encourage large files. A Go package consists of every Go source file in a directory. You can use as many or as few files as you want per package.