We replaced the title with something more neutral.
This category of submissions is not very good for HN, unfortunately. There isn't enough information there to slow down the gears, which is what allows for reflective reactions. In fact, there almost isn't any information, just 'celebrity name' and 'thing mentioned'. That produces the instant reflexive reactions that are associated with low-quality threads, and the celebrity aspect is a fuel supplement.
But can it traverse a NAT. IPSec for all of its benefits is a huge PITA to circumvent a NAT, often requiring either the NAT to have native support or for IPSec to be configured to use UDP encapsulation. Seems like the Wireguard people thought of this:
Reading their web site in general has made me nothing but impressed, they seem to be building a VPN tunneling protocol designed for the real world but with several improvements over existing solutions. It is incomplete, but definitely something I'm going to check in on.
https://news.ycombinator.com/item?id=17659983 is a decent thread from a couple of days ago which should tell you a bit more about its current state, the experiences of people installing it and running it and has a bunch of comments from the author.
The comment in question only talks about theoretical top speeds and he doesn't actually do any benchmarking. I'd like to see some actual tests before they write it off.
He does the math to prove that when you subtract all the mandatory protocol and frame headers you end up with practical maximum of 949.28 Mbps on 1 Gbps line. Providing charts with 1011 Mbps in favor of WireGuard makes all the comparison at least dubious. Another thing he mentioned is the test compares ChaCha20 cipher with AES256-GCM which is totally unfair.
Why would you invest so much in perfect code then to fake the benchmarks?
Regarding the 1011Mbps figure: the graph _suggests_ the measurements are compared to powers of two (the axis is in powers of two and the line right next to the bar _suggests_ the maximum would be 1024), so I would be more inclined to believe there may have been a mix-up between mebibits/sec and megabits/sec, or something IEC/SI units related somewhere in the measurements?
IMHO I don't think that the author would have any reason to fake the benchmarks (because it actually is an amazing piece of software), but I admit I like to err on the side of "assume good intentions".
Those benchmarks are ancient and the values being reported are confusing, but they're certainly not faked. I need to run new ones on a wider variety of hardware in a wider variety of circumstances and provide scripts to reproduce easily. It'd be nice to have lots of user submitted benchmarks of different environments.
At Expensify we have been astonished by how easy it was to set up -- as simple as ssh -- and its incredible performance relative to OpenVPN. It's night and day due to it's multi threaded design, meaning it doesn't have the same single cpu bottleneck as OpenVPN. It's clearly the future.
23 comments
[ 3.8 ms ] story [ 80.3 ms ] threadNot exactly the same thing as the title suggests. (FTR: the original title was something like "Linus Torvalds: Wireguard is a work of art")
This category of submissions is not very good for HN, unfortunately. There isn't enough information there to slow down the gears, which is what allows for reflective reactions. In fact, there almost isn't any information, just 'celebrity name' and 'thing mentioned'. That produces the instant reflexive reactions that are associated with low-quality threads, and the celebrity aspect is a fuel supplement.
Impress performance: https://www.wireguard.com/performance/
But can it traverse a NAT. IPSec for all of its benefits is a huge PITA to circumvent a NAT, often requiring either the NAT to have native support or for IPSec to be configured to use UDP encapsulation. Seems like the Wireguard people thought of this:
https://www.wireguard.com/quickstart/#nat-and-firewall-trave...
Reading their web site in general has made me nothing but impressed, they seem to be building a VPN tunneling protocol designed for the real world but with several improvements over existing solutions. It is incomplete, but definitely something I'm going to check in on.
(edit: rephrased for clarity)
The box in question implemented AES, RSA and DH. Does that mean AES, RSA and DH should be considered insecure too?