FIPS just locks you into a specific (generally fairly old) version of everything and sets some more annoying defaults. The only benefit is to be able to check a box on a form saying you qualify.

FIPS is pain

I feel like the issue with FIPS is not even the lagging behind, but the fact that FIPS-approved algorithms are often harder to implement than non-FIPS alternatives.

WireGuard itself is the perfect example: ChaCha20-Poly1305 is relatively simple to implement without screwing up. Curve25519 fits as well. Blake2s is fast even with only 32-bit integers.

A good AES implementation without any subtle vulnerabilities is hard. They left plenty of footguns on the table for you. DJB has plenty of criticisms of secp256r1 and similar curves, which is why Ed25519 and Curve25519 exist in the first place.

The algorithms might be fine, but the difficulty and complexity increases the odds that something will go wrong. Even your trusted implementation might have a bug or get one later, and there's more places for those to hide.

In the process of becoming CMMC compliant. Contractor is supposedly "the best in the industry and well respected" but is clearly ignorant of anything beyond the most basic MS AD setup paired with Cisco Gear. My favorite part is the security policies CMMC requires are bonkers like IT needing to evaluate and white list individual websites. So if a worker is doing research and needs to visit dozens of websites you have to do a security audit of the site and white list each one. -OR- you can pay a monthly fee to some rent seeking middle man who maintains a vetted white list. All these policies do is invent new ways for people to grift companies.

> fractal layers of ossified cruft

Someone got a thesaurus in their coffee today! (Not a jab)

but wolfssl is in the business of selling FIPS compliance so…

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.

For most people, wireguard is fine.

Edit: I should have said "choice" instead of "issue", but Firefox 140 is failing on this site so I could not correct the txt. I was able to edit this after reverting back to Firefox 128.

Crypto wise, fips is outdated but not horrible.

Actual fips compliant (certified) gives you confidence in some basic competence of the solution.

Just fips compatible (i.e. picking algos that could be fips compliant) is generally neutral to negative.

I'm not 100% up to date, so that might have changed, but AEAD used to be easier if you don't follow fips than fips compatible. Still possible, but more foot guns due to regulatory lag in techniques.

Overall, IMO the other top-level comment of "only fips if you have pencil pusher benefit" applies.

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.

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.

If you're considering whether to use a FIPS 140-3 module for your cryptography, consider that FIPS 140-3 is really only for specific compliance verticals. If you don't know whether you need it, you probably don't need it.

So, along those lines, if you wonder whether a package's cryptography should be FIPS 140-3 compliant, then the real question is whether you are a vertical that needs to be compliant. Again, if you aren't sure, the answer is likely NO.

No.

Getting a crypto module validated by FIPS 140-3 simply lets you sell to the US Government (something something FedRAMP). It doesn't give you better assurance in the actual security of your designs or implementations, just verifies that you're using algorithms the US government has blessed for use in validated modules, in a way that an independent lab has said "LGTM".

You generally want to layer your compliance (FIPS, etc.) with actual assurance practices.

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

No, there are not.

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

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.

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

In fairness, modern versions of FIPS are much less awful. AFAICT it's now possible to be FIPS compliant and 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.

"WolfGuard" is a different word than "WireGuard."

The ciphers used by WireGuard are not FIPS 140-3 certified. So you have to also change the ciphers, as is done in this project.

Are you talking about side channel attacks? Because AFAIK nonce reuse is an issue in both cases.

I don't understand the concern here?