Comment by dathery
1 year ago
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.
WireGuard is an instantiation of Noise, which slightly disfavors AES-GCM (see: the spec). I don't think it's a huge big deal, but at the time WireGuard was being designed it was pretty normal to tack away from GCM.
I agree in advance, Noise already uses counter-based nonces, the extended nonce wouldn't matter to vanilla Noise.
1 reply →
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...
It genuinely might not matter, and it might make sense to use a weaker protocol, if the only threat model you're trying to deal with is someone physically tapping a campus-area network. You'd run the "real" secure transports on top of that, the same way you do on internal networks today. In which case, yeah, it might make sense to select your protocol/constructions purely based on encryption efficiency.