alt.hn

3/24/2026 at 3:51:55 PM

WolfGuard: WireGuard with FIPS 140-3 cryptography

 https://github.com/wolfssl/wolfguard

by 789c789c789c

3/24/2026 at 4:33:25 PM

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.

by AaronFriel

3/24/2026 at 7:35:37 PM

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.

by jandrese

3/24/2026 at 6:59:32 PM

FIPS is pain

by UltraSane

3/24/2026 at 8:32:56 PM

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.

by gormami

3/24/2026 at 9:26:09 PM

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.

by ronsor

3/24/2026 at 9:46:01 PM

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?

by tptacek

3/24/2026 at 9:38:36 PM

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.

by MisterTea

3/25/2026 at 12:13:42 AM

Are you referring to SC.L2-3.13.6?

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 :)

by gnarlynarwhal42

3/24/2026 at 4:49:16 PM

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.

by elevation

3/24/2026 at 5:25:55 PM

> fractal layers of ossified cruft

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

by dmbche

3/24/2026 at 5:05:50 PM

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

by LtWorf

3/24/2026 at 5:07:36 PM

And they do it fast, thankfully Compliant Static Code Analyser catches issues like https://github.com/wolfSSL/wolfGuard/commit/fa21e06f26de201b...

by alfanick

3/24/2026 at 5:40:01 PM

Holy shit. Those are rookie mistakes[1], that could end up being SEVERE.

[1] Not referring to the fixes.

by johnisgood

3/24/2026 at 6:43:39 PM

looks like AI to me. It’s always making rookie mistakes that look plausible!

by dietsche

3/24/2026 at 6:51:43 PM

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.

by johnisgood

3/24/2026 at 5:23:23 PM

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.

by jmclnx

3/24/2026 at 5:26:55 PM

Could you expand on the design flaw in question?

by LunaSea

3/24/2026 at 5:30:48 PM

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.

by eptcyka

3/24/2026 at 5:42:38 PM

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

by tptacek

3/24/2026 at 6:39:27 PM

It is, we did the same. It is a shame that only Linux supports proper fake TCP though.

by eptcyka

3/24/2026 at 6:43:24 PM

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.

by coppsilgold

3/24/2026 at 6:47:32 PM

You can host a decoy on the server side.

by eptcyka

3/24/2026 at 6:52:46 PM

I don't suppose you'd release it, please?

by mmooss

3/24/2026 at 6:53:45 PM

It's part of `flyctl`, which is open source.

by tptacek

3/24/2026 at 6:27:44 PM

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

by gruez

3/24/2026 at 7:15:46 PM

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.

by cyberax

3/24/2026 at 7:51:19 PM

[dead]

by randomstuffs

3/24/2026 at 5:07:36 PM

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.

by usui

3/24/2026 at 5:48:25 PM

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.

by ongy

3/24/2026 at 5:13:40 PM

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.

by loeg

3/24/2026 at 5:20:14 PM

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.

by briandw

3/24/2026 at 6:25:26 PM

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.

by IncRnd

3/24/2026 at 8:36:46 PM

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

by derektank

3/24/2026 at 6:45:56 PM

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.

by some_furry

3/24/2026 at 5:09:23 PM

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

by alfanick

3/24/2026 at 5:13:23 PM

You failed to answer the question. Why did you reply?

by NewJazz

3/24/2026 at 5:43:04 PM

No, there are not.

by tptacek

3/24/2026 at 6:47:33 PM

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.

by coppsilgold

3/25/2026 at 12:27:49 AM

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.

by rainsford

3/25/2026 at 3:07:20 AM

I think cryptography engineers increasingly agree with this take, but it's also a different world: it would be straightforward to do XAES and modern P-curve implementations (now that they've been worked out with complete addition and stuff like that) now, but that was less the case when WireGuard was first published.

by tptacek

3/24/2026 at 7:49:41 PM

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

by tptacek

3/24/2026 at 7:52:21 PM

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.

by coppsilgold

3/24/2026 at 5:02:27 PM

So a step backward in security ?

by PunchyHamster

3/24/2026 at 5:10:05 PM

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.

by kstrauser

3/24/2026 at 5:21:18 PM

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.

by loeg

3/24/2026 at 10:07:43 PM

I wish they would just add ChaCha20-Poly1305 and Blake2 to FIPS, instead of ushering in the era of WireGuard forks.

by poemxo

3/24/2026 at 6:56:14 PM

Are there benchmarks available to compare vanilla wireguard to fips wireguard?

by gte525u

3/24/2026 at 8:42:32 PM

How will this avoid trademark issues with WireGuard?

by MrDrMcCoy

3/24/2026 at 9:06:41 PM

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

by loeg

3/24/2026 at 9:17:18 PM

Trademark infringement has a whole category for similarity.

by MrDrMcCoy

3/24/2026 at 10:51:06 PM

If Donenfeld wants them to change the name, they can change the name. I don't think this is a huge problem.

by loeg

3/24/2026 at 7:18:42 PM

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.

by kittikitti

3/24/2026 at 4:50:19 PM

Can't you also get FIPS 140-3 WireGuard by compiling wireguard-go with the new native FIPS support in Go?

by pphysch

3/24/2026 at 4:59:43 PM

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.

by inahga

3/24/2026 at 5:19:06 PM

E.g., ChaPoly AEAD -> AES-GCM, Blake2s -> SHA2/3, that kind of thing.

by loeg

3/24/2026 at 7:01:49 PM

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

by cookiengineer

3/24/2026 at 8:06:24 PM

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

by arter45

3/24/2026 at 7:50:25 PM

I don't understand the concern here?

by tptacek