4 ms·

Wireguard isn't so different from previous protocols establishing encrypted tunnels. Functionally it's IPSEC tunnel mode with all the complexities of IPSEC remo

Wireguard isn't so different from previous protocols establishing encrypted tunnels. Functionally it's IPSEC tunnel mode with all the complexities of IPSEC removed. With a bit of multipoint goodness (ala DMVPN) sprinkled in. The reason why it's hyped is because it's a non-encumbered, gratis, libre, fast replacement for OpenVPN. Yes, it doesn't handle algorithm negotiation. So if there's something wrong with the algorithms it's chosen, then we'll need a Wireguard 2. That's a design choice that trades off one thing (protocol independence and resilience) for another (simplicity and ease of implementation).

tptacek 5y ago
No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software security and cryptography engineers generally trust it more than any alternative protocol. (f) As a result of all of this, it is absurdly simple to configure and get running. Yes, IPSEC does a bunch of stuff WireGuard doesn't do. Yes, that's the tradeoff WireGuard made. Making that tradeoff is (a) the point of WireGuard and (b) the reason people like it so much.
- starfallg 5y ago
  > (d) As a result of all of this, it is very fast. No, it's very fast because the ChaCha/Salsa20 stream cipher uses common CPU instructions and runs fast in purely software, whereas AES requires things like S-Box computations which is slow in software but fast when implemented as accelerated instructions in hardware. There are IPSEC software stacks using AES acceleration that runs just as fast, not to mention IPSEC hardware offload. OpenVPN is slow due to architectural constraints, but IPSEC doesn't suffer from that at all. IPSEC tunnels with PSK is also absurdly easy to configure, either on Linux, or a router, what it doesn't offer is native NAT traversal.
  - tptacek 5y ago
    You are the first person who has ever told me that IPSEC was absurdly easy to configure. Share a configuration that illustrates the point?
    - herio 5y ago
      What is commonly called IPsec is actually two separate protocols, IPSec itself and ISAKMP/IKE for key management. IPSec is somewhat similar to how wireguard work actually, it relies on IPs and static encryption keys. Not too hard to configured, see for example the manual keying documentation of slackware: https://book.huihoo.com/slackware-linux-basics/html/ipsec.html#AEN3788 https://book.huihoo.com/slackware-linux-basics/html/ipsec.ht... ISAKMP/IKE is then used on top to manage the IPsec keys and parameters. This is where a lot of the complexity comes in, tons of parameters, modes, etc. etc. So if all you want is to secure communication between two IPs and can securely exchange key material out of bands, manually keyed IPsec is not very complicated.
      - psanford 5y ago
        IPSEC without IKE is not "similar to how wireguard works actually." Wireguard does actual key exchange and has security properties such as Forward Secrecy that you don't get using a hardcoded IPSEC symmetric key. Also, even the IPSEC config without IKE is way more complicated than a Wireguard config, with seriously sharp edges. Just look at that config you linked to. No one should ever need to know what AH and ESP are, but if you don't you very easily can configure IPSEC in an insecure manner.
      - tptacek 5y ago
        Is that your absurdly simple configuration? Can I assume the contents of that web page are where you rest your case on WireGuard's `wg.conf` vs. IPsec?
- nuker 5y ago
  > Doesn't have selectable or negotiable algorithms and constructions. NSA likes that. https://blog.cryptographyengineering.com/2015/10/22/a-riddle-wrapped-in-curve/ https://blog.cryptographyengineering.com/2015/10/22/a-riddle...
- benou 5y ago
  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.
  - api 5y ago
    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.
  - tptacek 5y ago
    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.
    - benou 5y ago
      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/packet_throughput_graphs/ipsec-3n-skx-xxv710.html 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.

tptacek 5y ago

No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software security and cryptography engineers generally trust it more than any alternative protocol. (f) As a result of all of this, it is absurdly simple to configure and get running. Yes, IPSEC does a bunch of stuff WireGuard doesn't do. Yes, that's the tradeoff WireGuard made. Making that tradeoff is (a) the point of WireGuard and (b) the reason people like it so much.

starfallg 5y ago
> (d) As a result of all of this, it is very fast. No, it's very fast because the ChaCha/Salsa20 stream cipher uses common CPU instructions and runs fast in purely software, whereas AES requires things like S-Box computations which is slow in software but fast when implemented as accelerated instructions in hardware. There are IPSEC software stacks using AES acceleration that runs just as fast, not to mention IPSEC hardware offload. OpenVPN is slow due to architectural constraints, but IPSEC doesn't suffer from that at all. IPSEC tunnels with PSK is also absurdly easy to configure, either on Linux, or a router, what it doesn't offer is native NAT traversal.
- tptacek 5y ago
  You are the first person who has ever told me that IPSEC was absurdly easy to configure. Share a configuration that illustrates the point?
  - herio 5y ago
    What is commonly called IPsec is actually two separate protocols, IPSec itself and ISAKMP/IKE for key management. IPSec is somewhat similar to how wireguard work actually, it relies on IPs and static encryption keys. Not too hard to configured, see for example the manual keying documentation of slackware: https://book.huihoo.com/slackware-linux-basics/html/ipsec.html#AEN3788 https://book.huihoo.com/slackware-linux-basics/html/ipsec.ht... ISAKMP/IKE is then used on top to manage the IPsec keys and parameters. This is where a lot of the complexity comes in, tons of parameters, modes, etc. etc. So if all you want is to secure communication between two IPs and can securely exchange key material out of bands, manually keyed IPsec is not very complicated.
    - psanford 5y ago
      IPSEC without IKE is not "similar to how wireguard works actually." Wireguard does actual key exchange and has security properties such as Forward Secrecy that you don't get using a hardcoded IPSEC symmetric key. Also, even the IPSEC config without IKE is way more complicated than a Wireguard config, with seriously sharp edges. Just look at that config you linked to. No one should ever need to know what AH and ESP are, but if you don't you very easily can configure IPSEC in an insecure manner.
    - tptacek 5y ago
      Is that your absurdly simple configuration? Can I assume the contents of that web page are where you rest your case on WireGuard's `wg.conf` vs. IPsec?
nuker 5y ago
> Doesn't have selectable or negotiable algorithms and constructions. NSA likes that. https://blog.cryptographyengineering.com/2015/10/22/a-riddle-wrapped-in-curve/ https://blog.cryptographyengineering.com/2015/10/22/a-riddle...
benou 5y ago
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.
- api 5y ago
  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.
- tptacek 5y ago
  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.
  - benou 5y ago
    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/packet_throughput_graphs/ipsec-3n-skx-xxv710.html 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.