Hacker News Reader

Comment by dathery | Hacker News Reader

Really cool article, I enjoy reading through all the details behind the decision making.

Just spit-balling a little, but I wonder if Wireguard is the best tool here given that the author is only using it for a single point-to-point link and they control the devices on both ends. That CPU supports AES-NI and probably does it a lot faster than Wireguard's ChaCha20 (hard to get numbers for their server CPU, but the tiny little x86 mini PC I use as my router does AES XTS at 43Gbps according to `cryptsetup benchmark`).

You might see better performance by tunneling the vxlan connection using a different technology which can use AES-NI? Then again, Wireguard is definitely still a good tool for stuff like this, and maybe the performance penalty isn't a big deal here.

View on HN

AES can only encrypt up to 64TB; after that you need to re-key. So you need a mechanism for rekeying anyway. Definitely a good idea to use a battle-tested tool like wireguard instead of rolling your own.

>AES can only encrypt up to 64TB

I've never heard that before. Are you referring to a specific mode of operation?

I think alphager is referring to the upper limits of AES before a birthday attack becomes a concern. In GCM mode there's a realistic chance of an IV being reused after around 64GB of data. Other modes have differing limits.

Presumably this depends on the block size? GP did not specify.

Umm... IPsec?

Truly. I think IPSec is practically more "battle tested" than wireguard ever could be, and IPSec offers more useful functionality than wireguard ever will.

Because Wireguard is cool and AES is uncool.

I guess it depends on whether you're more concerned about transport security or cipher cycles/byte.

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.

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.

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.

This has been nagging at me for a day, so just to clarify real quick:

I wanted to push back a little on the notion that Chapoly was "cool" and GCM was "lame" back in 2015-2016. At the time, GCM was coming off a pretty rough run of implementation bugs. It was the tail end of a period of time where a concern was that some mainstream architectures wouldn't be able to run performant constant-time GCM at all; like, the fast software GCMs had a table-driven multiplication? I forget the details.

But you could have done a secure WireGuard instantiated on AES-GCM. It's true that GCM was out of fashion and Chapoly was in fashion. I just want to say, that fashion had (has?) some real technical roots. That's all.

Reply on news.ycombinator.com