Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am not challenging that Wireguard is a great technology, but I disagree it is faster than IPsec: it is fast compared to slow IPsec implementation such as the one you have in Linux.

However, AES is hw-accelerated in most systems those days and as a result, using IPsec with AES-256-GCM is usually much faster than Wireguard [1]. Note that if Wireguard was using AES instead of Chach20-Poly1305 I am sure it would be on par, plus I am confident we'll see hw acceleration for Chacha20-Poly1305 in the future too.

So I'd say right now if you need absolute max performance, a good IPsec implementation is much faster than Wireguard.

[1] for example, just running 'openssl speed -evp chacha20-poly1305' vs 'openssl speed -evp aes-256-gcm' on my laptop gives a ~2x speed advantage to AES.



This is a big reason why ZeroTier is moving to AES for its symmetric crypto. It's not only a lot faster but much more power efficient. The blazing speeds with ARX ciphers are only achievable using vector or other parallel constructions that light up the whole ALU, using many times more power than AES hardware.

Using AES with GMAC I can clock from 2-4GiB/sec/core on typical laptops and over 1GiB/sec on phones. The Apple M1 does almost 5GiB/sec/core. Gen10 and newer Intel CPUs with VAES have produced benchmarks in excess of 10GiB/sec/core, which means a single core could theoretically saturate 100gig fiber if it were just doing crypto.

Of course nothing stops CPU makers from adding ARX accelerator instructions, but I have yet to see any proposed. If constructions like ChaCha and BLAKE2/BLAKE3 get popular enough I could see this happening.


Post numbers on a good IPsec implementation? We have numbers for WireGuard. Of course, it's easy to do that because there's just a couple primary implementations, not 100 terrible ones like in IPsec. So, pick the best one.

We don't have to derive the answer to this question from first principles. It's an empirical question.


Here is an example for VPP, ~8Gbps/core of IPsec forwarding with AES-256-GCM and IMIX traffic on Skylake @2.3GHz: https://docs.fd.io/csit/master/report/vpp_performance_tests/...

Note that thanks to AES-NI vectorization (an example of hw acceleration I was referring to) it reaches more than 16Gps/core on the same test on Icelake.

Those numbers can grow up to 50% for big packets (1500-bytes and higher).

With a high performance stack, IPsec (and Wireguard for that matter) workloads are limited by crypto performance, not packet processing performance, and the perf difference between IPsec with AES-256-GCM and Wireguard is basically the perf difference of AES-256-GCM vs Chacha20-Poly1305 of your platform.


This is DPDK-style user-mode direct/raw networking, isn't it?


Yes. But VPP also supports Wireguard, and when doing apple-to-apple comparisons, the performance difference between Wireguard vs IPsec AES-256-GCM is close to 2x. See https://fosdem.org/2021/schedule/event/sdn_calicovpp/attachm... slides 23 and 26: 5Gbps of Wireguard vs 9.5Gbps of IPsec.

And the main reason is the cipher: one is hw-assisted (AES-NI on x86), the other is not.

Again, I do think Wireguard is nice because it is a clean sheet design with good choices and it "just works". However when I hear "Wireguard is faster than IPsec" it is not true in my experience, and can be easily explain by the cipher choice.


>I am confident we'll see hw acceleration for Chacha20-Poly1305 in the future too.

The speed gains wouldn't be as significant. AES uses S-Box computations that do well when hardware accelerated, whereas ChaCha/Salsa20 are designed to use more typical CPU instructions for bitwise operations.


Speed gains maybe not, however on current x86 platform there is a 2x perf difference between AES-256-GCM and Chacha20-Poly1305, so even if we get "only" 2x I'd be delighted.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: