(Tailscale cofounder) I see a few comments here that using kernel wireguard would make it faster; it’s not really that simple. In fact, for a while (and we wrote a blog post about it), our optimizations made wireguard-go faster than kernel wireguard because it was better optimized. They adopted some of those improvements and now we’re on to the next order of magnitude together.
For really high bandwidth cases, things like DPDK are the long term best choice and are primarily userspace, for good reasons. Kernel mode is not the pure benefit it once was (if it ever was).
Separately, wireguard itself has a problem that the crypto suite it uses is not supported by hardware accelerators. So if we want to get into the hundreds of gigabits range, we will possibly need to switch packet formats entirely. (But, wireguard also needs to update to support post-quantum so maybe they’ll fix both problems at the same time and we can join in.)
1) Besides marketing, I see no reason that Tailscale needs to concern itself with the WireGuard protocol spec at all. Tailscale is already incompatible.
2) Tailscale's control plane model for peer distribution avoids every concern affecting IPsec in regard to protocol negotiation security and compatibility.
TL;DR, diverging from WireGuard & supporting AES (via protocol negotiation with hardware acceleration), would be relatively painless.
You lose the formally-verified cryptography guarantees underpinning WireGuard & its implementation, though. That's a bigger tradeoff: <a href="https://www.wireguard.com/protocol/" rel="nofollow">https://www.wireguard.com/protocol/
Implementation requires different considerations, no? For example, AES-GCM needs to be supplied a big-endian nonce, whilst ChaPoly uses little-endian. As the WireGuard paper notes, ChaPoly (in software) can be better protected against (CPU) side-channels. Besides extended-nonce AEAD being "native" to ChaPoly, BLAKE family of hash functions that WireGuard uses, are also based on the same construction as ChaPoly, making the implementation leaner (something Jason keenly emphasizes as an advantage).
No. I specifically said, "lose the formally-verified cryptography guarantees underpinning WireGuard & its implementation" and I pointed out the implementation quirks.
Anywho, given your strong conviction about this, consider suggesting to Jason on the WireGuard mailing list to swap ChaPoly for AES-GCM, or perhaps consider a fork yourself. Good luck.
apenwarr · · focus · HN ↗
For really high bandwidth cases, things like DPDK are the long term best choice and are primarily userspace, for good reasons. Kernel mode is not the pure benefit it once was (if it ever was).
Separately, wireguard itself has a problem that the crypto suite it uses is not supported by hardware accelerators. So if we want to get into the hundreds of gigabits range, we will possibly need to switch packet formats entirely. (But, wireguard also needs to update to support post-quantum so maybe they’ll fix both problems at the same time and we can join in.)
iscoelho · · focus · HN ↗
2) Tailscale's control plane model for peer distribution avoids every concern affecting IPsec in regard to protocol negotiation security and compatibility.
TL;DR, diverging from WireGuard & supporting AES (via protocol negotiation with hardware acceleration), would be relatively painless.
ignoramous · · focus · HN ↗
You lose the formally-verified cryptography guarantees underpinning WireGuard & its implementation, though. That's a bigger tradeoff: <a href="https://www.wireguard.com/protocol/" rel="nofollow">https://www.wireguard.com/protocol/
iscoelho · · focus · HN ↗
ignoramous · · focus · HN ↗
iscoelho · · focus · HN ↗
You used AI to write that, didn't you? Please don't do that, it's disrespectful.
ignoramous · · focus · HN ↗
Anywho, given your strong conviction about this, consider suggesting to Jason on the WireGuard mailing list to swap ChaPoly for AES-GCM, or perhaps consider a fork yourself. Good luck.