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.

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 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.

So a step backward in security ?

Are there benchmarks available to compare vanilla wireguard to fips wireguard?

This is a great project, thanks for sharing. I'll be following the repository even though I don't plan on changing any of my WireGuard deployments.

Can't you also get FIPS 140-3 WireGuard by compiling wireguard-go with the new native FIPS support in Go?

> XChaCha20-Poly1305 replaced with AES-256-GCM

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.