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.
[1] Not referring to the fixes.
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.
>OpenVPN does not store any of your private data, including IP addresses, on VPN servers, which is ideal.
https://www.pcmag.com/comparisons/openvpn-vs-wireguard-which...
I thought openvpn had some weird wrapper on top of TLS that makes it easily detectable? Also to bypass state of the art firewalls (eg. China's gfw), it's not sufficient to be just "tls". Doing TLS-in-TLS produces telltale statistical signatures that are easily detectable, so even simpler protocols like http CONNECT proxy over TLS can be detected.
OpenVPN is fine if you want to tunnel through a hotel network that blocks UDP, but it's useless if you want to defeat the Great China Firewall or similar blocks.
Someone got a thesaurus in their coffee today! (Not a jab)
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.
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.
Likely no, I agree. But I think there are probably a lot of companies selling enterprise software that later attempt to solicit a FedRAMP authorization that would benefit from planning ahead and building a compliant version from the jump. Worth considering and having a conversation internally.
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.
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...
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.
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.
The intent of this control is absolutely not to require a whitelist of individual websites.
This control is meant to apply to ports and protocols aka tighten up and document your firewall rules
If you are referring to SI.L2-3.14.7, you also do not need to whitelist websites. A pDNS service helps here but is not required. There are free options available, one of which is offered to small businesses in the DIB through the NSA's CCC program. This also gets you vulnerability scanning and some other stuff, all free.
Let me know if you have any questions. CMMC isnt a cakewalk but it needs to be done right if you don't want to fail your $40k C3PAO assessment :)