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.<p>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.
> fractal layers of ossified cruft<p>Someone got a thesaurus in their coffee today! (Not a jab)
Yes, but be aware, openvpn is much better if you live in a Country like China, Russia and a few others. That is due to a known design issue with wireguard.<p>For most people, wireguard is fine.
but wolfssl is in the business of selling FIPS compliance so…
And they do it fast, thankfully Compliant Static Code Analyser catches issues like <a href="https://github.com/wolfSSL/wolfGuard/commit/fa21e06f26de201bf9139bf742f514ef9ddf4f28#diff-d0f0f5117b6e6bc7d9b9c8ae7197cf26cf0f972c6f056b689960c0b7f778ce36R253" rel="nofollow">https://github.com/wolfSSL/wolfGuard/commit/fa21e06f26de201b...</a>
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.
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.
My limited understanding is that issues like being vulnerable to side channel attacks are very difficult to detect. So you have to have shown that the entire development process is safe. From the code to the compiler to the hardware to the microcode, it all needs to be checked. That said it does seem like compliance is a bigger priority than safety.
There is no security advantages or technical grounds for using FIPS algorithms in a WireGuard clone instead of Chacha / Blake2. It's purely a compliance move. ChaPoly, Blake2, etc, are not known to be broken and we have every reason to believe they are strong.
I presume it's a product strategy to provide a box of "compliant" libraries/services, so other companies can quickly tick and sign a checkbox saying "we use compliant VPN", because someone else is going to look whether the checkbox is ticked and signed, because someone else is going to...
So a step backward in security ?
In fairness, modern versions of FIPS are much less awful. AFAICT it's now possible to be FIPS compliant <i>and</i> meet reasonable crypto expectations, which was not always the case before.
It's fine. None of the FIPS algorithms are known to be broken, either. The only risk here is implementation bugs doing the conversion and any maintenance burden incurred due to diverging from upstream wireguard.
Can't you also get FIPS 140-3 WireGuard by compiling wireguard-go with the new native FIPS support in Go?