3 ms·

It's unfortunate that WireGuard doesn't include a switch that if both sides agree the crypto in use would be AES and SHA256. Not due to FIPS compliance but perf

It's unfortunate that WireGuard doesn't include a switch that if both sides agree the crypto in use would be AES and SHA256. Not due to FIPS compliance but performance and power savings. I never once used WireGuard on hardware that didn't have AES and SHA intrinsics, all that battery wasted.

tptacek 7mo ago
A core part of the security design of WireGuard is not negotiating cryptography.
- coppsilgold 7mo ago
  No one suggests the negotiated mess that exists in most standards. A single binary switch to account for hardware acceleration when it's available on both ends would have been a good decision.
smashed 7mo ago
This is addressed on the known issues page [1]. Basically it does not need dedicated hw acceleration because it can use generic vector instructions to reach similar speeds. I wonder how true that is though. [1]: https://www.wireguard.com/known-limitations/#:~:text=WireGuard%20uses%20ChaCha20Poly1305%2C%20which%20is,)%20than%20AES%2DNI%20instructions. https://www.wireguard.com/known-limitations/#:~:text=WireGua...
rainsford 7mo ago
I'll take the possibly controversial position that WireGuard's opinionated approach to cryptographic choices without the option for negotiation was indeed the right call, but it would have been a better and even more successful protocol if it used FIPS compliant cryptography. Taking the DJB crypto path gave Wireguard some subtle advantages to implementation ease-of-use that are almost entirely overshadowed by the difficultly in building a new, secure cryptographic protocol from scratch regardless of what algorithms you're using. The tradeoff was that there are plenty of places it will never be used due to standards compliance requirements which as you point out also has significant implications for efficiency in hardware. Wireguard is cool. I think very little of that coolness has to do with the DJB vs NIST cryptographic choices. And taking the DJB path unnecessarily limited the impact of its coolness at least for now.
- tptacek 7mo ago
  I think cryptography engineers increasingly agree with this take, but it's also a different world: it would be straightforward to do XAES and modern P-curve implementations (now that they've been worked out with complete addition and stuff like that) now, but that was less the case when WireGuard was first published.

tptacek 7mo ago

A core part of the security design of WireGuard is not negotiating cryptography.

coppsilgold 7mo ago
No one suggests the negotiated mess that exists in most standards. A single binary switch to account for hardware acceleration when it's available on both ends would have been a good decision.

smashed 7mo ago

This is addressed on the known issues page [1]. Basically it does not need dedicated hw acceleration because it can use generic vector instructions to reach similar speeds. I wonder how true that is though. [1]: https://www.wireguard.com/known-limitations/#:~:text=WireGuard%20uses%20ChaCha20Poly1305%2C%20which%20is,)%20than%20AES%2DNI%20instructions. https://www.wireguard.com/known-limitations/#:~:text=WireGua...

rainsford 7mo ago

I'll take the possibly controversial position that WireGuard's opinionated approach to cryptographic choices without the option for negotiation was indeed the right call, but it would have been a better and even more successful protocol if it used FIPS compliant cryptography. Taking the DJB crypto path gave Wireguard some subtle advantages to implementation ease-of-use that are almost entirely overshadowed by the difficultly in building a new, secure cryptographic protocol from scratch regardless of what algorithms you're using. The tradeoff was that there are plenty of places it will never be used due to standards compliance requirements which as you point out also has significant implications for efficiency in hardware. Wireguard is cool. I think very little of that coolness has to do with the DJB vs NIST cryptographic choices. And taking the DJB path unnecessarily limited the impact of its coolness at least for now.

tptacek 7mo ago
I think cryptography engineers increasingly agree with this take, but it's also a different world: it would be straightforward to do XAES and modern P-curve implementations (now that they've been worked out with complete addition and stuff like that) now, but that was less the case when WireGuard was first published.