Notes

WireGuard Crypto, FIPS, and the AES-NI Tax

WireGuard chose modern primitives that are fast in software. FIPS pushes VPNs toward validated AES modules. Can mainline WireGuard ever fit that world?

Why I wrote this

A question that keeps coming up in government and regulated-industry contexts: can we use WireGuard if we need FIPS?

essay 11 min read
Cryptography Infrastructure Security

WireGuard is fast. Not just “fast for a VPN” fast, but fast enough that the cryptographic overhead largely disappears into the noise of normal network operations. It achieves this without requiring any special hardware. That is not an accident. It is a direct consequence of the cryptographic primitives it chose.

And it is exactly the reason mainline WireGuard, as designed, is unlikely to be FIPS 140-2 or 140-3 validated without becoming a different protocol.

The WireGuard cipher suite

WireGuard’s protocol is deliberately opinionated. There is no cipher negotiation. Every peer uses the same construction:

  • ChaCha20-Poly1305 for authenticated encryption
  • Curve25519 for key exchange (via Noise IK)
  • BLAKE2s for hashing and keyed MAC
  • SipHash for hashtable keys

None of these are FIPS-approved for the roles WireGuard uses them in. All of them were chosen because they are fast in pure software on commodity hardware, including embedded systems, mobile devices, and low-power ARM boards.

Why ChaCha20 is fast without hardware

AES is a substitution-permutation network. Its operations (SubBytes, ShiftRows, MixColumns, AddRoundKey) map elegantly onto dedicated silicon. Intel’s AES-NI instruction set collapses multiple rounds into a single instruction, and with AES-NI present, AES-GCM is extraordinarily fast.

Without AES-NI, though, software AES implementations face a choice: either use lookup tables (which are vulnerable to cache-timing side channels) or use bitsliced implementations that are constant-time but slow.

ChaCha20 is an ARX cipher: add, rotate, XOR. These are the three cheapest operations on any general-purpose CPU. There is no need for lookup tables, no risk of cache-timing attacks, and no dependence on specialized instructions. A ChaCha20 implementation that is constant-time is also the natural, obvious implementation. You get security and performance by default.

Insight

AES needs special hardware to be both fast and safe at high throughput. ChaCha20 is designed to be fast and constant-time across general-purpose CPUs.

The same philosophy extends to the rest of the suite. Curve25519 was designed for efficient, constant-time field arithmetic on commodity processors. BLAKE2s is faster than SHA-256 in software while providing equivalent security margins.

The FIPS problem

FIPS 140-2 and its successor FIPS 140-3 do not approve VPN protocols wholesale. They validate cryptographic modules and require those modules to use approved security functions. For VPN-style authenticated encryption in the current CMVP ecosystem, that usually means AES-GCM or AES-CCM from a validated module. For hashing, it means SHA-2, SHA-3, and approved SHA-3-derived functions. For key establishment, it means SP 800-56A-compliant ECDH over approved NIST curves (P-256, P-384, P-521, etc.) or finite-field DH.

ChaCha20-Poly1305 is not approved for this use. X25519 key agreement, the Curve25519 construction WireGuard uses, is specifically not SP 800-56A-compliant. BLAKE2s and SipHash are not in the approved hash or MAC set.

This is not a matter of these algorithms being considered insecure. ChaCha20-Poly1305 is standardized for IETF protocols and is a SHOULD-implement TLS 1.3 cipher suite. X25519 is widely deployed and well-analyzed. But FIPS validation is a standards and testing process, not a general endorsement of every sound primitive. An algorithm must be approved for the relevant use, and then a specific implementation of that algorithm must be tested and validated by an accredited lab.

Warning

“Not FIPS-approved” does not mean “not secure.” It means the algorithm, use, or implementation is outside the approved FIPS validation boundary. These are very different statements.

The AES-NI tax

Here is the practical consequence for regulated environments.

If your compliance framework requires FIPS for the VPN layer, you are probably using AES-GCM or AES-CCM through a validated cryptographic module. If you use AES and you want it to be both fast and resistant to side-channel attacks, you want hardware AES acceleration: AES-NI on x86, ARMv8 Crypto Extensions on newer ARM platforms, or an equivalent accelerator. This means your VPN infrastructure has a hardware dependency that WireGuard’s default cipher suite largely avoids.

This matters most at the edges. Core x86 data center servers almost universally have AES-NI, and newer ARM server platforms usually have their own crypto extensions. But IoT devices, embedded gateways, older ARM boards, and low-cost edge hardware often do not. In those environments, a FIPS-mandated VPN carries a real performance penalty, or worse, falls back to implementations with timing vulnerabilities.

WireGuard sidesteps this entirely. Its performance characteristics are consistent from a Raspberry Pi to a rack server.

Will mainline WireGuard ever be FIPS?

Probably not in any meaningful sense without changing what people mean by WireGuard. Here is why.

The algorithm barrier. WireGuard would need to swap its entire cipher suite: ChaCha20-Poly1305 for AES-GCM, Curve25519 for P-256 ECDH, BLAKE2s for SHA-256. This is not a tweak. It is a different protocol. The Noise framework WireGuard is built on does support pluggable primitives in theory, but WireGuard’s design philosophy explicitly rejects cipher agility. The simplicity and auditability of the codebase depend on having exactly one path through the cryptography.

The implementation barrier. Even if someone forked WireGuard and replaced the primitives, that fork would need to go through FIPS validation using a validated cryptographic module. This is expensive, slow, and operationally specific: validation applies to particular modules, versions, and operating environments. Vendors can build FIPS-oriented integrations around WireGuard-like software, but that is not the same as mainline WireGuard becoming FIPS validated.

The philosophical barrier. Jason Donenfeld, WireGuard’s author, has been explicit that cipher agility is a non-goal. The project regards it as a source of complexity and vulnerabilities, pointing to the long history of downgrade attacks and negotiation bugs in IPsec and TLS. Adding FIPS cipher suites would undermine the core design thesis.

Tip

If you need a FIPS-validated VPN today, IPsec with IKEv2 (using strongSwan or Libreswan with a validated crypto module) remains the standard answer. It is more complex to configure, but the FIPS ecosystem around it is mature.

What could change

There is one scenario where WireGuard and FIPS converge cleanly: NIST could approve ChaCha20-Poly1305 and X25519 for the relevant uses. NIST’s approved algorithm portfolio is not frozen; recent additions include SHA-3-derived functions, post-quantum signature and key-establishment standards, and Ascon-based lightweight cryptography. But that movement does not currently make WireGuard’s cipher suite FIPS-approved.

But “ongoing discussion” at NIST operates on a timeline measured in years, not months. Do not plan your compliance roadmap around it.

The moat is getting smaller, but the gatekeepers remain

It is worth understanding how the FIPS ecosystem has shifted, and why that shift does not help WireGuard as much as you might expect.

A validated FIPS cryptographic module used to be a serious competitive moat. Building one meant a six- or seven-figure investment in lab testing, months of back-and-forth with an accredited lab, and ongoing maintenance costs every time the module changed. Companies that had validated modules, particularly proprietary VPN and TLS appliance vendors, could charge a premium because their customers had no cheaper alternative. If your procurement required FIPS, your vendor list was short and your prices were high.

That has eroded. OpenSSL 3.x has a validated FIPS provider module that applications can build around. AWS-LC has its own FIPS module. Go is moving away from the older Go+BoringCrypto path toward a native Go Cryptographic Module intended to support FIPS 140-3 compliance, with validation status tied to specific module versions. These projects do not make arbitrary application code FIPS-compliant by magic, but they have lowered the financial barrier to building on FIPS-validated or FIPS-oriented cryptography.

Insight

FIPS validation used to be a product differentiator. Open source FIPS modules have made approved cryptography much easier to consume. The moat that proprietary crypto vendors once enjoyed is smaller than it used to be.

Historically, the British East India Company held Crown-granted monopoly rights over major Asian trade routes for over two centuries. The Company’s ships were not bad; many were well-built and well-crewed. But the licensing regime that made them mandatory (and let the Company charge monopoly prices) was the real source of their market power. Parliament narrowed that monopoly in stages: the India trade monopoly ended in 1813, the China and tea monopoly ended in 1833, and the Company’s governing functions were transferred to the Crown in 1858. The change was legislative, not nautical. Open-source FIPS modules are the equivalent legislative change: they did not make the proprietary vendors’ implementations worse, but they collapsed the licensing barrier that made those implementations the only option.

But this commoditization cuts in a specific direction. It makes mainstream approved primitives such as AES-GCM, P-256 ECDH, SHA-2, and SHA-3 easier to consume. It does not make WireGuard’s primitives approved. And here is where institutional inertia matters.

Installed-base inertia. AES is not literally the only approved symmetric primitive; NIST has added Ascon-based lightweight cryptography for constrained devices. But for high-throughput VPN AEAD in the current FIPS ecosystem, AES-GCM remains the mainstream path. Hardware vendors, appliance vendors, cloud providers, and security teams have all invested around that path. Approving ChaCha20-Poly1305 would remove a constraint that currently channels regulated VPN deployments toward AES-accelerated platforms, but the organizations already optimized for AES have little urgency to change that default.

The standards-process inertia. NIST’s cryptographic standards process is not purely technical. It involves public comment periods, industry input, migration cost, implementation availability, validation burden, and judgment about what the government should endorse. Large vendors and agencies have more capacity to participate in that process than small open source projects. That does not imply conspiracy or bad faith; it means the status quo has representation, documentation, and deployment history behind it.

The “good enough” problem. From NIST’s perspective, the current approved set works. AES is secure. AES-GCM is fast on modern hardware. The post-quantum transition is consuming enormous institutional bandwidth. There is no urgent security reason to approve ChaCha20, even if there are excellent engineering reasons. In a resource-constrained standards body, “the current algorithms are not broken” is a powerful argument for doing nothing.

In the 1840s the US Navy resisted steam propulsion. The sail advocates’ strongest argument was genuinely sound: wind is free, proven, and the entire fleet is optimized for it. And they were right. Sail worked well for known missions. But steam offered consistent performance regardless of conditions, while sail degraded unpredictably when the wind died. The Navy adopted steam not because sail failed, but because the mission envelope expanded to demand reliability that wind could not guarantee. ChaCha20 is in a similar position: AES-GCM works well on hardware with AES-NI, but ChaCha20 delivers consistent performance across the full range of deployment targets, from rack servers to Raspberry Pis, without depending on specialized instructions that may or may not be present.

None of this is conspiracy. It is ordinary institutional behavior: standards bodies prioritize urgent problems, organizations protect existing investments, and the status quo has inertia proportional to the deployment built on top of it. But the practical effect is that the technical path to WireGuard-and-FIPS convergence, NIST approving ChaCha20-Poly1305 and X25519 for the relevant uses, faces headwinds that are institutional and economic, not just procedural.

The pragmatic middle ground

For organizations that want WireGuard’s simplicity but face FIPS requirements:

  • Use WireGuard for non-regulated traffic and IPsec for traffic subject to FIPS mandates. Network segmentation makes this tractable.
  • Document the risk decision. If your authorizing official will accept a system where the VPN layer uses non-FIPS crypto but all data at rest and application-layer encryption is FIPS-validated, this may be defensible depending on your authority’s risk tolerance.
  • Watch the standards. NIST’s post-quantum migration work is forcing a broader rethink of approved algorithms. The approved algorithm list five years from now will look different than it does today.

WireGuard made a deliberate engineering choice: modern, efficient cryptography over compliance checkbox compatibility. For most of the internet, that is the right tradeoff. For regulated environments whose VPN layer must use approved cryptography, it means mainline WireGuard is not a clean option, and it may never be, at least not the WireGuard we know today.

Sources