The conventional wisdom in cryptography is that if you don't know you need FIPS, if you don't have paper and a dollar figure telling you how much you need it, you don't need or want FIPS.
Wireguard exemplifies the superiority of a qualified independent developer over the fractal layers of ossified cruft that you get from industry efforts and compliance STIGS.
So it feels wrong to see wireguard adapted for compliance purposes. If compliance orgs want superior technology, let their standards bodies approve/adopt wireguard without modifying it.
I know software developers complain about forced compliance due to the security theatre aspects, but I would like to charitably ask from someone who has technical understanding of FIPS-compliant cryptography. Are there any actual security advantages on technical grounds for making WireGuard FIPS-compliant? Assume the goal is not to appease pencil pushers. I really want to know if this kind of effort has technical gains.
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.
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.
For all those saying that FIPS is a step backwards in crypto, you are right, the standards always lag the state of the art. That said, CMMC is coming into it's own in the US MilGov space, and a LOT of small businesses need to be CMMC compliant, which requires FIPS certified crypto. So having an open sourced FIPS compliant option is a good thing for them. Good on WolfSSL for helping out that space.
14 comments
[ 2.7 ms ] story [ 36.5 ms ] threadSo it feels wrong to see wireguard adapted for compliance purposes. If compliance orgs want superior technology, let their standards bodies approve/adopt wireguard without modifying it.
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.
What could possibly go wrong? It's not like every CTF ever designed has a block cipher or counter mode challenge. /s
If the project wasn't done by WolfSSL, I would have assumed it's a trolling attempt to mock FIPS requirements. But it's not, and that's the problem.