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.
No, I mean, for example uninitialized pointers are a huge red flag, so seeing one not set to NULL is honestly shocking, especially in crypto code where a stray pointer can lead to crashes or subtle security issues.
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.
OpenVPN looks like a regular tls stream - difficult to distinguish between that and a HTTPS connection. WireGuard looks like WireGuard. But you can wrap WireGuard in whatever headers you might want to obfuscate it and the perf will still be better.
It's trivial to make WireGuard look like a regular TLS stream. It's probably not worth a 15 year regression in security characteristics just to get that attribute; just write the proxy for it and be done with it. It was a 1 day project for us (we learned the hard way that a double digit percentage of our users simply couldn't speak UDP and had to fix that).
Doesn't the Chinese firewall perform sophisticated filtering? Fake TCP should not be difficult to catch. I recall reading how the firewall uses proxies to initiate connections just to see whats up.
>OpenVPN looks like a regular tls stream - difficult to distinguish between that and a HTTPS connection.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
> 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…
And they do it fast, thankfully Compliant Static Code Analyser catches issues like https://github.com/wolfSSL/wolfGuard/commit/fa21e06f26de201b...
Holy shit. Those are rookie mistakes, that could end up being SEVERE.
looks like AI to me. It’s always making rookie mistakes that look plausible!
No, I mean, for example uninitialized pointers are a huge red flag, so seeing one not set to NULL is honestly shocking, especially in crypto code where a stray pointer can lead to crashes or subtle security issues.
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.
Could you expand on the design flaw in question?
OpenVPN looks like a regular tls stream - difficult to distinguish between that and a HTTPS connection. WireGuard looks like WireGuard. But you can wrap WireGuard in whatever headers you might want to obfuscate it and the perf will still be better.
It's trivial to make WireGuard look like a regular TLS stream. It's probably not worth a 15 year regression in security characteristics just to get that attribute; just write the proxy for it and be done with it. It was a 1 day project for us (we learned the hard way that a double digit percentage of our users simply couldn't speak UDP and had to fix that).
It is, we did the same. It is a shame that only Linux supports proper fake TCP though.
Doesn't the Chinese firewall perform sophisticated filtering? Fake TCP should not be difficult to catch. I recall reading how the firewall uses proxies to initiate connections just to see whats up.
You can host a decoy on the server side.
I don't suppose you'd release it, please?
It's part of `flyctl`, which is open source.
>OpenVPN looks like a regular tls stream - difficult to distinguish between that and a HTTPS connection.
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.
It is not a design flaw, but a design choice.
>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...
Are there benchmarks available to compare vanilla wireguard to fips wireguard?
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.
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.
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.
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.
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.
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...
You failed to answer the question. Why did you reply?
No, there are not.
So a step backward in security ?
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.
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.
Can't you also get FIPS 140-3 WireGuard by compiling wireguard-go with the new native FIPS support in Go?
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.
E.g., ChaPoly AEAD -> AES-GCM, Blake2s -> SHA2/3, that kind of thing.