Is there reason to think AES used appropriately would be any less secure here? Not trying to be argumentative, genuinely curious.
My understanding is that AES has some design warts that make it not ideal (basically, it's easy to both implement and use in ways that leak information if you're not careful) but that it's still essentially perfect symmetric encryption if you're using it as recommended. Is that wrong?
FWIW, the reason I brought up performance was because the OP spends a large chunk of the post talking about it, so I assume it's an important requirement for them.
It's not about AES, it's about the WireGuard protocol. AES is fine. It's possible that, if Jason had the decisions to do over again today, he might use XAES instead of ChaPoly (he didn't have an especially good AES construction to use at the time). The big thing with WireGuard is not doing ciphersuite negotiation, which is an extremely good decision that is definitely worth paying some cycles/byte for (if you must).
Maybe I'm missing something, but why would he have needed XAES rather than vanilla AES-GCM, which was certainly available at the time WireGuard was created? XAES gives you large nonces which is cool, but that's not something WireGuard needs AFAIK and it's not something regular ChaPoly gives you anyways.
Now I admit ChaPoly has some pretty nice advantages if you're implementing it in software. But with the trend of AES-GCM hardware support and the long-lived nature of WireGuard's crypto choices given the lack of ciphersuite negotiation (which I agree was a good decision!), I'm not sure AES-GCM wouldn't have been the best (albeit less cool) choice.
Although maybe on the other hand, ChaPoly can still be made to run pretty fast even just in software and it gives WireGuard the advantage of being more practical on very low-end devices that might lack AES-GCM hardware. Avoiding ciphersuite negotiation means a tradeoff needs to be made somewhere, at least with current algorithms, and I'd bet line-rate hardware encryption is probably the least likely place to see WireGuard for a while at least, so maybe WireGuard did make the best tradeoff at the time.
AES is probably fine as a cipher but the VPN protocols that aren't Wireguard tend to have various footguns available. In theory someone could create NoisyESP but I'm not aware of it.
That makes sense. I was thinking they could use something like DTLS [1] and tunnel just the one UDP port needed for their VXLAN connections, rather than use full-blown VPN software. I have never actually tried this myself though.
Is there reason to think AES used appropriately would be any less secure here? Not trying to be argumentative, genuinely curious.
My understanding is that AES has some design warts that make it not ideal (basically, it's easy to both implement and use in ways that leak information if you're not careful) but that it's still essentially perfect symmetric encryption if you're using it as recommended. Is that wrong?
FWIW, the reason I brought up performance was because the OP spends a large chunk of the post talking about it, so I assume it's an important requirement for them.
It's not about AES, it's about the WireGuard protocol. AES is fine. It's possible that, if Jason had the decisions to do over again today, he might use XAES instead of ChaPoly (he didn't have an especially good AES construction to use at the time). The big thing with WireGuard is not doing ciphersuite negotiation, which is an extremely good decision that is definitely worth paying some cycles/byte for (if you must).
Maybe I'm missing something, but why would he have needed XAES rather than vanilla AES-GCM, which was certainly available at the time WireGuard was created? XAES gives you large nonces which is cool, but that's not something WireGuard needs AFAIK and it's not something regular ChaPoly gives you anyways.
Now I admit ChaPoly has some pretty nice advantages if you're implementing it in software. But with the trend of AES-GCM hardware support and the long-lived nature of WireGuard's crypto choices given the lack of ciphersuite negotiation (which I agree was a good decision!), I'm not sure AES-GCM wouldn't have been the best (albeit less cool) choice.
Although maybe on the other hand, ChaPoly can still be made to run pretty fast even just in software and it gives WireGuard the advantage of being more practical on very low-end devices that might lack AES-GCM hardware. Avoiding ciphersuite negotiation means a tradeoff needs to be made somewhere, at least with current algorithms, and I'd bet line-rate hardware encryption is probably the least likely place to see WireGuard for a while at least, so maybe WireGuard did make the best tradeoff at the time.
2 replies →
AES is probably fine as a cipher but the VPN protocols that aren't Wireguard tend to have various footguns available. In theory someone could create NoisyESP but I'm not aware of it.
That makes sense. I was thinking they could use something like DTLS [1] and tunnel just the one UDP port needed for their VXLAN connections, rather than use full-blown VPN software. I have never actually tried this myself though.
[1] https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...
1 reply →