Re:Why Not WireGuard (2020)
by tptacek on Sunday October 17, 2021 @12:38PM
(#28897681)
People have spent a year dunking on this article, because it is bad. I just want to jump in with a quick dunk/aside about cryptographic primitives.
The article tries to argue that the cryptography in IKEv2 and IPSEC is comparable to that of WireGuard. After all, there are RFCs for Curve25519 in IKEv2, and Chapoly in IPSEC.
This pattern of argument frustrates the hell out of me. You see it all the time in discussions about PGP as well, where any conceivable cryptographic primitive has either been standardized or POC'd somewhere in the ecosystem. Leave aside interoperability (nonexistent) and negotiation (dangerous). The argument still doesn't hold!
Just because you've got a Curve25519 formula somewhere in your design doesn't mean it's directly comparable with anything else that uses Curve25519. The tricky bits are in the joinery, not in the primitives. WireGuard does a NoiseIK-based triple DH handshake --- it performs an authenticated key exchange, one that MITMs can't intercept, using only the DH primitive. In the closest comparable mode of deployment, IKEv2 uses digital signatures to authenticate exchanges, backed by X509(!) certificates. IKEv2's AKE is much more complicated, hard to assess for security on its own terms, and implicates some giant historic security nightmare code paths. Avoiding those code tar pits is explicitly part of the security design of WireGuard.
Nobody should concede the point that IPSEC allows users to opt in to WireGuard-level crypto modernity. You can't just swap Curve25519 for Diffie Hellman Group #14 and call it a day. You should be skeptical of people who make claims that you can.
The article tries to argue that the cryptography in IKEv2 and IPSEC is comparable to that of WireGuard. After all, there are RFCs for Curve25519 in IKEv2, and Chapoly in IPSEC.
This pattern of argument frustrates the hell out of me. You see it all the time in discussions about PGP as well, where any conceivable cryptographic primitive has either been standardized or POC'd somewhere in the ecosystem. Leave aside interoperability (nonexistent) and negotiation (dangerous). The argument still doesn't hold!
Just because you've got a Curve25519 formula somewhere in your design doesn't mean it's directly comparable with anything else that uses Curve25519. The tricky bits are in the joinery, not in the primitives. WireGuard does a NoiseIK-based triple DH handshake --- it performs an authenticated key exchange, one that MITMs can't intercept, using only the DH primitive. In the closest comparable mode of deployment, IKEv2 uses digital signatures to authenticate exchanges, backed by X509(!) certificates. IKEv2's AKE is much more complicated, hard to assess for security on its own terms, and implicates some giant historic security nightmare code paths. Avoiding those code tar pits is explicitly part of the security design of WireGuard.
Nobody should concede the point that IPSEC allows users to opt in to WireGuard-level crypto modernity. You can't just swap Curve25519 for Diffie Hellman Group #14 and call it a day. You should be skeptical of people who make claims that you can.