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.

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.

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.

So a step backward in security ?

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

WolfGuard VPN with FIPS 140-3 cryptography

WolfGuard is the wolfSSL FIPS-compliant refactor of Linux kernel-based WireGuard, originally designed and authored by Jason Donenfeld. Usage is essentially identical. There are two principal components to WolfGuard, the wolfguard.ko kernel module and the wg-fips configuration tool. wolfguard.ko depends on the libwolfssl.ko kernel module, and wg-fips depends on the libwolfssl.so library — these dependencies are built from the same wolfSSL source, with kernel module and user library configuration respectively. The wg-fips-quick script works exactly like wg-quick in WireGuard, but with configuration scripts in /etc/wolfguard containing SECP256R1 public and private keys.

Symbolic links are installed in the installation bin directory from wg to wg-fips, and from wg-quick to wg-fips-quick, for transparent drop-in replacement of WireGuard. If WireGuard executables are found during installation, they are renamed to wg-wireguard and wg-wireguard-quick, with wg-wireguard-quick modified to call wg-wireguard, and with a safety copy left at wg-wireguard-quick.unpatched.

WolfGuard remaps cryptography from WireGuard as follows:

Algo category	WireGuard	WolfGuard
ECDH	Curve25519	SECP256R1
AEAD	XChaCha20-Poly1305	AES-256-GCM
digest	Blake2s	SHA2-256
authenticating digest	Blake2s-HMAC	SHA2-256-HMAC
internal hash	SipHash	SHA2-256
DRBG	ChaCha20 DRBG	SHA2-256 Hash-DRBG

Note that WolfGuard and WireGuard can coexist on the same system, simultaneously establishing WolfGuard and WireGuard tunnels.

If libwolfssl.ko is configured with --enable-intelasm, performance of WolfGuard matches or exceeds that of CPU-accelerated WireGuard, thanks to CPU acceleration of the AES-256-GCM and SHA2-256 operations. Without --enable-intelasm, WolfGuard is slightly slower than CPU-accelerated WireGuard, but is still capable of saturating gigabit ethernet on modern CPUs.

Building and Installation

Below are two sets of instructions, the first for building from non-FIPS sources, and the second for building from FIPS-certified sources. In both cases, the WolfGuard user tool and script are named wg-fips and wg-fips-quick, reflecting their use of FIPS-approved algorithms regardless of FIPS certification status. FIPS-certified and non-certified builds of WolfGuard are fully interoperable with each other, but cannot interoperate with WireGuard.

The --enable-intelasm option should only be used with x86 CPU targets, and for FIPS, only on FIPS sources that support it. Contact us at fips@wolfssl.com for more info.

The --enable-wolfguard option enables the minimum library/module feature set required for WolfGuard. For a more comprehensive feature set, use --enable-all-crypto instead.

Commands prefixed with $ should be executed by an unprivileged user, while those with # are to be executed with root privileges, but in the same established working directory context.

Note that if a wolfSSL release archive is used in lieu of git sources, the release must be version 5.8.4 or newer.

Building and installing non-FIPS `git` sources

(1) Create a top level directory for the sources and populate it:

$ mkdir wolf-sources
$ cd wolf-sources
$ git clone https://github.com/wolfssl/wolfssl --branch nightly-snapshot
$ git clone https://github.com/wolfssl/wolfguard
$ (cd wolfssl && ./autogen.sh)

(2) Build and install the libwolfssl user library:

Note, this step is optional on Linux, where by default wg-fips offloads key generation and conversion operations to the kernel module, rather than performing them internally.

$ cd wolfssl
$ ./configure --quiet --enable-wolfguard --enable-all-asm
$ make -j
$ ./wolfcrypt/test/testwolfcrypt
# make install
$ cd ..

(3) Build and install the wg-fips user tool -- note, installation will move existing WireGuard wg and wg-quick executables and man pages in the destination directories (if present) to wg-wireguard and wg-wireguard-quick respectively, and will install symbolic links for wg and wg-quick that point to the WolfGuard versions.

$ cd wolfguard/user-src
$ make -j
# make install
$ cd ../..

To force use of internal key ops on Linux, rather than the default offload to the kernel module, replace make -j with make -j NO_IPC_LLCRYPTO=1.

Support is available for compressed public keys, whose base64 exported lengths are the same as WireGuard Curve25519 public keys. This can be enabled by substituting

$ make -j EXTRA_CFLAGS=-DWG_USE_PUBLIC_KEY_COMPRESSION

in the above. Note, however, that WolfGuard with WG_USE_PUBLIC_KEY_COMPRESSION is incompatible with default WolfGuard settings -- when set, compressed public keys are supplied and expected, both in local configuration and in over-the-wire negotiations.

(4) Build and install the libwolfssl kernel module. Replace /usr/src/linux with the path to your actual target kernel source tree, which must be fully configured and built, and precisely match the kernel you will boot on your target system. The modprobe at the end assumes you are targeting the native running system.

$ cd wolfssl
$ ./configure --quiet --enable-wolfguard --enable-cryptonly --enable-intelasm \
   --enable-linuxkm --with-linux-source=/usr/src/linux \
   --prefix=$(pwd)/linuxkm/build
$ make -j module
# make install
# modprobe libwolfssl

Before you put the libwolfssl kernel module in production, you should build and load it with extended self-test enabled. Replace the ./configure recipe above with the following:

$ ./configure --quiet --enable-wolfguard --enable-cryptonly --enable-intelasm \
   --enable-linuxkm --with-linux-source=/usr/src/linux \
   --prefix=$(pwd)/linuxkm/build --enable-crypttests \
   CFLAGS=-DWOLFSSL_LINUXKM_VERBOSE_DEBUG

The extra options are not appropriate for production, but a module configured with them should be loaded in a representative runtime environment to confirm that all algorithms function correctly.

(5) Build and install the WolfGuard kernel module. Again, replace /usr/src/linux with the path to your actual target kernel source tree, and replace 6.16.5-gentoo with the actual value returned by uname -r on the target system. And again, the modprobe after the build assumes you are targeting the native running system.

$ cd ../wolfguard/kernel-src
$ make -j KERNELDIR=/usr/src/linux KERNELRELEASE=6.16.5-gentoo
# make install
# modprobe wolfguard
$ ../user-src/wg-fips genkey | ../user-src/wg-fips pubkey

The KERNELRELEASE value is, effectively, the verbatim name of the directory under /lib/modules/ where the target kernel's modules are installed.

The genkey and pubkey ops in the final line are basic functionality tests. If all is well, it will succeed, and print a random public key.

As for the wg-fips build above, compressed public key support can be enabled by adding EXTRA_CFLAGS=-DWG_USE_PUBLIC_KEY_COMPRESSION to the above make recipe. The WG_USE_PUBLIC_KEY_COMPRESSION setting must be matched throughout the ecosystem.

If all of the above succeeds, then you are now ready to bring up WolfGuard tunnels. Existing playbooks and scripting for WireGuard can be used directly, provided you substitute /etc/wolfguard for /etc/wireguard, and generate all keys using the WolfGuard wg-fips tool (wg will at this point be a link to wg-fips).

Building and installing FIPS sources

FIPS certified versions of the wolfssl source archive are supplied separately. Contact fips@wolfssl.com.

(1) Create a top level directory for the sources and populate it. This procedure assumes a wolfssl archive in 7z format -- substitute tar -xf if the archive is a .tar.gz. In either case, adjust the ln -s recipe to assure wolfssl is a symbolic link to the extracted wolfssl directory. Also note that FIPS kernel module archives are distinct from non-kernel archives, though they are safe to use for building the FIPS user library, as shown below.

$ mkdir wolf-sources
$ cd wolf-sources
$ 7z x ~/Downloads/wolfssl-X-fips-linuxvX-kernel.7z
$ ln -s wolfssl-X-fips-linuxvX-kernel wolfssl
$ git clone https://github.com/wolfssl/wolfguard

(2) Build and install the libwolfssl user library.

Note, this step is optional on Linux, where by default wg-fips offloads key generation and conversion operations to the kernel module, rather than performing them internally.

$ cd wolfssl
$ ./configure --quiet --enable-fips=vX --enable-wolfguard
$ make -j
$ ./fips-hash.sh
$ make -j
$ ./wolfcrypt/test/testwolfcrypt
# make install
$ cd ..

Note, the argument to --enable-fips must match the FIPS flavor of the archive. Currently the most apt arguments for WolfGuard usage are v5.2.4 and v6.

$ cd wolfguard/user-src
$ make -j
# make install
$ cd ../..

To force use of internal key ops on Linux, rather than the default offload to the kernel module, replace make -j with make -j NO_IPC_LLCRYPTO=1.

This is a two-step process. First you will build and install the module with an incorrect integrity hash. Then you will load it to capture the correct hash, which will exit early with an expected “Operation canceled” error. Then you will rebuild and load the module with the correct hash. Note that these instructions assume targeting the native system. Note also that the lowest libwolfssl FIPS version compatible with Linux kernel mode is v5.2.4.

$ cd wolfssl
$ ./configure --quiet --enable-fips=vX --enable-wolfguard --enable-cryptonly \
   --enable-linuxkm --with-linux-source=/usr/src/linux \
   --prefix=$(pwd)/linuxkm/build
$ make -j module
# make install
# modprobe libwolfssl

(Expect early exit of the above modprobe, with an “Operation canceled” message.)

$ NEWHASH=$(dmesg | awk '{if (match($0, " new hash \"([^\"]+)\" ", hash_a)) { hash = hash_a[1]; }} END {print hash}')
$ sed --in-place=.bak "s/^\".*\";/\"${NEWHASH}\";/" wolfcrypt/src/fips_test.c
$ make -j module
# make install
# modprobe libwolfssl

If the second modprobe fails like the first one, with another "Update verifyCore[] in fips_test.c with new hash ..." message in the kernel log, then your toolchain and/or target kernel configuration are defeating reproducible build. In that case, you should use this alternative strategy, replacing the steps after the NEWHASH= command above:

$ make module-update-fips-hash FIPS_HASH="$NEWHASH"
# make install
# modprobe libwolfssl

Before you put the libwolfssl kernel module in production, you should build and load it with extended self-test enabled. To do this, replace the ./configure recipe above with the following:

$ ./configure --quiet --enable-fips=vX --enable-wolfguard --enable-cryptonly \
   --enable-linuxkm --with-linux-source=/usr/src/linux \
   --prefix=$(pwd)/linuxkm/build --enable-crypttests \
   CFLAGS=-DWOLFSSL_LINUXKM_VERBOSE_DEBUG

The extra options are not appropriate for production, but a module configured with them should be loaded in a representative runtime environment to confirm that all algorithms function correctly.

$ cd ../wolfguard/kernel-src
$ make -j KERNELDIR=/usr/src/linux KERNELRELEASE=6.16.5-gentoo
# make install
# modprobe wolfguard
$ ../user-src/wg-fips genkey | ../user-src/wg-fips pubkey

The genkey and pubkey ops in the final line are basic functionality tests. If all is well, it will succeed, and print a random public key.

As with the non-FIPS-certified procedure, if all of the above succeeds, then you are now ready to bring up WolfGuard tunnels. Existing playbooks and scripting for WireGuard can be used directly, provided you substitute /etc/wolfguard for /etc/wireguard, and generate all keys using the WolfGuard wg-fips tool (wg will at this point be a link to wg-fips). However, note that some WireGuard client applications and automation frameworks expect WireGuard public keys to be exported with exactly 44 characters of base64. WolfGuard public keys are roughly twice that length, unless built with WG_USE_PUBLIC_KEY_COMPRESSION, which is not currently supported in FIPS v5, but is supported in FIPS v6 and later.

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…

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.

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.

So a step backward in security ?

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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?

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.

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.

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.

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.

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[1], that could end up being SEVERE.

[1] Not referring to the fixes.

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

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

No.

You generally want to layer your compliance (FIPS, etc.) with actual assurance practices.

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

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

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

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

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

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.

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

[1] Not referring to the fixes.

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

>Again, if you aren't sure, the answer is likely NO.

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

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.

>OpenVPN looks like a regular tls stream - difficult to distinguish between that and a HTTPS connection.

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

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

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.

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.

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

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

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.

Hacker Times

Hacker Times

WolfGuard: WireGuard with FIPS 140-3 cryptography

Discussion

Discussion

WolfGuard VPN with FIPS 140-3 cryptography

Building and Installation

Building and installing non-FIPS `git` sources

Building and installing FIPS sources

Hacker Times

Hacker Times

WolfGuard: WireGuard with FIPS 140-3 cryptography

Discussion

Discussion

WolfGuard VPN with FIPS 140-3 cryptography

Building and Installation

Building and installing non-FIPS git sources

Building and installing FIPS sources

Building and installing non-FIPS `git` sources