[HN Gopher] WolfGuard: WireGuard with FIPS 140-3 cryptography
___________________________________________________________________
WolfGuard: WireGuard with FIPS 140-3 cryptography
Author : 789c789c789c
Score : 75 points
Date : 2026-03-24 15:51 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| AaronFriel wrote:
| 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.
| UltraSane wrote:
| FIPS is pain
| jandrese wrote:
| 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.
| elevation wrote:
| 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.
| LtWorf wrote:
| but wolfssl is in the business of selling FIPS compliance so...
| alfanick wrote:
| And they do it fast, thankfully Compliant Static Code
| Analyser catches issues like https://github.com/wolfSSL/wolfG
| uard/commit/fa21e06f26de201b...
| johnisgood wrote:
| Holy shit. Those are rookie mistakes[1], that could end up
| being SEVERE.
|
| [1] Not referring to the fixes.
| dietsche wrote:
| looks like AI to me. It's always making rookie mistakes
| that look plausible!
| johnisgood wrote:
| 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.
| jmclnx wrote:
| 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.
| LunaSea wrote:
| Could you expand on the design flaw in question?
| jmclnx wrote:
| 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...
| eptcyka wrote:
| 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.
| tptacek wrote:
| 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).
| eptcyka wrote:
| It is, we did the same. It is a shame that only Linux
| supports proper fake TCP though.
| coppsilgold wrote:
| 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.
| eptcyka wrote:
| You can host a decoy on the server side.
| mmooss wrote:
| I don't suppose you'd release it, please?
| tptacek wrote:
| It's part of `flyctl`, which is open source.
| gruez wrote:
| >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.
| cyberax wrote:
| Raw OpenVPN is very easy to distinguish, its handshake
| signature is very different from the regular TLS.
|
| 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.
| dmbche wrote:
| > fractal layers of ossified cruft
|
| Someone got a thesaurus in their coffee today! (Not a jab)
| pphysch wrote:
| Can't you also get FIPS 140-3 WireGuard by compiling wireguard-go
| with the new native FIPS support in Go?
| inahga wrote:
| 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.
| loeg wrote:
| E.g., ChaPoly AEAD -> AES-GCM, Blake2s -> SHA2/3, that kind
| of thing.
| PunchyHamster wrote:
| So a step backward in security ?
| kstrauser wrote:
| 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.
| loeg wrote:
| 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.
| usui wrote:
| 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.
| alfanick wrote:
| 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...
| NewJazz wrote:
| You failed to answer the question. Why did you reply?
| loeg wrote:
| 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.
| briandw wrote:
| 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.
| tptacek wrote:
| No, there are not.
| ongy wrote:
| 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.
| IncRnd wrote:
| 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.
| derektank wrote:
| >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.
| some_furry wrote:
| 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.
| coppsilgold wrote:
| 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.
| tptacek wrote:
| A core part of the security design of WireGuard is not
| negotiating cryptography.
| coppsilgold wrote:
| No one suggests the negotiated mess that exists in most
| standards. A single binary switch to account for hardware
| acceleration when it's available on both ends would have been
| a good decision.
| smashed wrote:
| 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...
| gte525u wrote:
| Are there benchmarks available to compare vanilla wireguard to
| fips wireguard?
| cookiengineer wrote:
| > 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.
| tptacek wrote:
| I don't understand the concern here?
| arter45 wrote:
| Are you talking about side channel attacks? Because AFAIK nonce
| reuse is an issue in both cases.
| kittikitti wrote:
| 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.
| gormami wrote:
| For all those saying that FIPS is a step backwards in crypto, you
| are right, the standards always lag the state of the art. That
| said, CMMC is coming into it's own in the US MilGov space, and a
| LOT of small businesses need to be CMMC compliant, which requires
| FIPS certified crypto. So having an open sourced FIPS compliant
| option is a good thing for them. Good on WolfSSL for helping out
| that space.
| ronsor wrote:
| 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.
| tptacek wrote:
| Ordinary implementers aren't doing de novo implementations of
| AES, and the gap between the P-curves and Curve25519 has
| closed, so this feels like a critique that might have been
| more germane 10-15 years ago?
| MisterTea wrote:
| 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.
| MrDrMcCoy wrote:
| How will this avoid trademark issues with WireGuard?
| loeg wrote:
| "WolfGuard" is a different word than "WireGuard."
| MrDrMcCoy wrote:
| Trademark infringement has a whole category for similarity.
| loeg wrote:
| If Donenfeld wants them to change the name, they can change
| the name. I don't think this is a huge problem.
| poemxo wrote:
| I wish they would just add ChaCha20-Poly1305 and Blake2 to FIPS,
| instead of ushering in the era of WireGuard forks.
___________________________________________________________________
(page generated 2026-03-24 23:01 UTC)