Four config lines. That's the diff between a standard WireGuard deployment and one that passes a FedRAMP audit.
WolfGuard , a new fork of WireGuard backed by wolfSSL's FIPS 140-3 validated cryptography module (certificate #4718) , quietly dropped its first public release last week. It rips out WireGuard's elegant but compliance-hostile crypto stack (Curve25519, ChaCha20-Poly1305, BLAKE2s) and routes everything through P-384 ECDH, AES-256-GCM, and SHA-384 instead. The team claims just 5% throughput loss compared to vanilla WireGuard.
I've been watching this space since Jason Donenfeld first pushed WireGuard into the Linux kernel. The protocol was a masterpiece of minimalism , around 4,000 lines of code versus OpenVPN's 100K+. But every time a government contractor or healthcare org tried to adopt it, the same wall appeared: none of WireGuard's primitives live on the NIST-approved list.
So I got on a call with two of the engineers behind WolfGuard to understand what they actually changed, what they didn't, and whether this thing holds up under real traffic.
Elegant Crypto That Compliance Refuses to Recognize
Q: WireGuard works. It's fast, it's simple, it's in the kernel. Why fork it?
Lead Engineer: WireGuard's crypto choices are arguably superior from a pure cryptography standpoint. Curve25519 is faster than P-384. ChaCha20 outperforms AES on hardware without AES-NI. BLAKE2s is a beast. But none of that matters when your compliance officer is holding a FIPS 140-3 checklist. The approved algorithms list is the approved algorithms list. You can't negotiate with it.
We had enterprise customers literally running two VPN stacks in parallel , WireGuard for performance-sensitive internal traffic, and some legacy IPsec solution for the audit trail. That's insane.
Q: How long has WireGuard's FIPS gap been a known issue?
Lead Engineer: Years. There are threads from 2019 asking about it. Jason himself has said WireGuard was designed for correctness and simplicity, not compliance checkbox engineering. That's a totally valid stance. But it left a massive deployment gap.
Inside the Crypto Swap: Noise IK Meets P-384
Q: Walk me through the crypto swap at the protocol level.
Protocol Engineer: The handshake was the biggest surgery. WireGuard uses Noise IK, which is built around Curve25519 DH operations. We replaced those with P-384 ECDH through wolfSSL's FIPS module. The Noise framework itself is flexible enough to support different DH functions, so the protocol structure stays intact.
For symmetric encryption, ChaCha20-Poly1305 becomes AES-256-GCM. Both are AEAD constructions, so the encrypt-then-MAC flow doesn't change. The transport data message format is essentially the same , just different bytes inside.
Hashing goes from BLAKE2s to SHA-384. Every KDF derivation, every MAC computation, all routed through the validated module.
Q: What does "routed through the FIPS module" actually mean in practice?
Protocol Engineer: Every cryptographic operation , key generation, ECDH computation, symmetric encryption, hashing , calls into wolfSSL's FIPS boundary. Module #4718 specifically. That module has been through CMVP testing. It enforces zeroization of key material, approved RNG seeding, and algorithm self-tests at startup. If any self-test fails, the module enters an error state and refuses to perform crypto. That's the compliance guarantee.
We don't implement any crypto ourselves. Zero custom cryptographic code. If it touches a key or a plaintext byte, it goes through wolfSSL.
Where the 5% Overhead Actually Lives
Q: The headline number is 5% throughput overhead. How did you measure that?
Lead Engineer: iperf3 between two machines on the same 10GbE switch. Both running kernel 6.6 , one with vanilla WireGuard, one with WolfGuard. We tested with 1400-byte MTU to simulate realistic VPN conditions.
Vanilla WireGuard hit around 6.2 Gbps. WolfGuard came in at 5.9 Gbps. Roughly a 5% delta.
Q: Where does that 5% go?
Protocol Engineer: Almost entirely AES-256-GCM versus ChaCha20-Poly1305. On modern Intel and AMD chips with AES-NI, the AES overhead is minimal. The P-384 versus Curve25519 difference only surfaces during handshakes, and WireGuard handshakes are infrequent by design , one handshake, then two minutes of packets before rekeying.
On ARM chips without hardware AES acceleration, the gap would widen. We haven't published ARM benchmarks yet. Those are coming.
Q: What about latency?
Protocol Engineer: Handshake latency is measurably higher. P-384 scalar multiplication is slower than Curve25519. We're seeing about 2ms of additional handshake time. For a VPN that renegotiates every 120 seconds, that's noise. Steady-state packet latency is within measurement error of vanilla WireGuard.
Migration in Minutes, Not Months
Q: How painful is the migration for existing WireGuard users?
Lead Engineer: We kept the config format identical. Your wg0.conf works as-is. Same [Interface] and [Peer] blocks. Same wg command-line tool. The only visible difference is that key generation produces P-384 keys instead of Curve25519, so you need to regenerate your keypairs.
The kernel module is a drop-in replacement. Remove wireguard, load wolfguard. That's it.
Q: Does this actually satisfy FedRAMP auditors? Have you tested it against a real audit?
Lead Engineer: wolfSSL's FIPS module has been used in FedRAMP-authorized systems before. The module itself carries the validation. Our job was to ensure every crypto call goes through that module and nothing leaks outside the FIPS boundary. We've had two independent assessors review the integration.
Will every auditor accept it without questions? Probably not. Compliance is a conversation, not a checkbox. But the cryptographic foundation is there.
What This Unlocks for the Broader Ecosystem
Q: Is this the end of the "WireGuard can't do compliance" argument?
Lead Engineer: For the FIPS-specific objection, yes. For compliance more broadly, VPN is just one piece. You still need FIPS-validated TLS stacks, FIPS-validated disk encryption , the whole chain. But the VPN gap was a particularly frustrating one because WireGuard is so obviously the right technical choice for most deployments.
Q: What's the upstream relationship? Any chance this lands in mainline WireGuard?
Protocol Engineer: We've had conversations. Jason's position is that WireGuard proper should remain opinionated about its crypto choices, and I respect that. WolfGuard will stay a maintained fork. We track upstream changes and rebase. The codebase diff is surprisingly small because we kept the same architecture , just different primitives plugged in.
The Skeptic's Case: NIST Curves Aren't a Free Lunch
Not everyone's celebrating. Some voices in the WireGuard community argue that swapping in NIST curves defeats the purpose of WireGuard's carefully chosen primitives. Curve25519 was selected specifically because it resists certain implementation pitfalls that P-384 is susceptible to. There's a legitimate cryptographic argument that NIST compliance makes the protocol marginally less safe against certain attack classes, even as it opens the door to regulated environments.
That's the tension. Security engineering versus compliance engineering. They're not always the same discipline.
What to Watch Next
WolfGuard ships a real answer to a real problem that has blocked WireGuard adoption in government and enterprise for years. The crypto swap is clean, the overhead is minimal, and config compatibility means existing deployments can migrate without rewriting their automation.
Three things to track from here: ARM performance numbers when they drop, real-world FedRAMP authorization stories from early adopters, and how quickly the fork keeps pace with upstream WireGuard development. The project's GitHub repo has the full source and build instructions. The wolfSSL FIPS module documentation covers the validation boundary details.
Four thousand lines of code changed the VPN landscape once. A few hundred more might just open the doors that were still locked.