# wolfSSL FIPS-eval Linux — Coverage Manifest ***wolfSSL FIPS-eval is a demo and presales evaluation channel. It is NOT FIPS-validated, NOT supported, and NOT for production use. The binaries are NOT the FIPS-certified bundle.*** This document is the algorithm coverage matrix for the wolfSSL FIPS-eval channel served at . The channel ships wolfSSL and wolfProvider built from public open-source wolfSSL with FIPS-approximating configure flags, so the binaries execute the same algorithms, through the same APIs, on the same code paths as the FIPS 140-3 validated wolfCrypt module — but these specific binaries are **not** under the wolfCrypt FIPS 140-3 certificate boundary (CMVP certificates #4718 and #5041). They are not acceptable as the cryptographic module for any deployment that must satisfy FIPS 140-3, CMMC, DoD or federal procurement, or any other regime that requires a NIST-validated module under an active certificate. wolfCrypt itself is dual-licensed: GPL-3.0 or commercial. The FIPS-eval channel distributes the GPL-3.0 build. For supported FIPS 140-3 validated wolfCrypt, production licensing, the actual FIPS-certified code, an actual FIPS certificate, and Operational Environment (OE) work, contact . See "Getting help, support, sales, licensing, and FIPS certification" at the bottom of this document. ## Distributions covered The FIPS-eval channel is published for: - **Debian**: Trixie (13), Bookworm (12) — amd64 + arm64 - **Fedora**: 43, 44 — x86_64 + aarch64 - **RHEL / Rocky / AlmaLinux / CentOS Stream**: 9, 10 — x86_64 + aarch64 ## Coverage matrix Two artifact form factors are covered: **OCI image** (shares the host kernel) and **qcow2 / AMI / OVA** (full system, ships its own kernel and userspace). | Layer | OCI image (shares host kernel) | qcow2 / AMI / OVA (full system) | |---|---|---| | Kernel crypto API (KCAPI / AF_ALG) | ✗ host kernel | ✗ not via wolfProvider | | `/dev/random`, `/dev/urandom`, `getrandom()` | ✗ host kernel | ✗ not via wolfProvider | | LUKS / dm-crypt disk encryption | N/A | ✗ not via wolfProvider | | Kernel TLS / IPsec | ✗ host kernel | ✗ not via wolfProvider | | WireGuard → WolfGuard | N/A | ✗ not via wolfProvider | | OpenSSL 3.x via wolfProvider | ✓ eval | ✓ eval | | GnuTLS via gnutls-wolfssl | ✓ eval | ✓ eval | | libgcrypt via libgcrypt-wolfssl | ✓ eval | ✓ eval | | NSS / Firefox / Thunderbird via wolfPKCS11 | ✓ eval | ✓ eval | | 35+ userspace apps inheriting wolfProvider | ✓ eval | ✓ eval | | Go applications (`crypto/tls` standard library) | ✗ not via wolfProvider | ✗ not via wolfProvider | | Go applications via go-wolfssl SDK | — | — | ### Cell legend - **`✓ eval`** — Serviced by an algorithm-identical FIPS-eval build of wolfCrypt. Same APIs, same code paths, same algorithms as the validated module; binary is not under the certificate boundary. - **`✗ host kernel`** — Not provided by this artifact. In an OCI container, the kernel is the host's. Whatever crypto the host kernel uses (typically unvalidated kernel-builtin crypto) is what these operations use. - **`✗ not via wolfProvider`** — Not provided by this artifact. The FIPS-eval apt repo does not ship a kernel module, WolfGuard, or a Go toolchain. Validated coverage of these layers exists under wolfSSL's Full Linux FIPS delivery engagement; it is not in the FIPS-eval pipeline. - **`N/A`** — The layer does not exist in this form factor. OCI containers do not perform block-device encryption or run their own kernel-mode VPN. - **`—`** — Not shipped in the FIPS-eval apt repo by design. See notes below. ## Notes ### What "FIPS-approximating" means The FIPS-eval channel ships wolfSSL built from public open-source wolfSSL with configure flags chosen to restrict the algorithm surface to those covered by wolfCrypt FIPS 140-3 certificates #4718 and #5041. Algorithm implementations, entry points, and API surface match the validated wolfCrypt module. The differences are procedural and structural: a validated build is the specific binary that went through a CMVP-accredited lab and is bound to a certificate covering a specific Operating Environment (CPU family, kernel version, build toolchain), and it includes power-on self-tests, RNG health tests, and module integrity checking that the eval build does not run. The FIPS-eval binaries are suitable for evaluating wolfSSL integration on your stack before committing to a validated delivery engagement; they are not suitable as the cryptographic module for a deployment that must satisfy FIPS 140-3. ### When you need validated If your deployment must satisfy FIPS 140-3, CMMC Level 2, DoD/federal procurement, or any regime that requires a NIST-validated cryptographic module under an active certificate, you need a validated build, not a FIPS-eval build. Validated wolfCrypt is delivered per Operating Environment — the validated boundary is specific to your CPU family, your kernel configuration, and your build toolchain — so it is per-engagement work rather than a downloadable package. Contact `facts@wolfssl.com` to scope a validated deployment for your specific hardware and kernel. ### Kernel-layer coverage The `libwolfssl.ko` kernel module that registers wolfCrypt algorithms with KCAPI / AF_ALG, and through that registration provides FIPS coverage for the kernel RNG, LUKS / dm-crypt, kernel TLS, IPsec, and WireGuard / WolfGuard, is **not** in the FIPS-eval apt repo. The kernel module is delivered as part of the Full Linux FIPS engagement, built against your exact kernel configuration with your module signing keys preserved. The OCI image form factor has no kernel-layer story by construction (it shares the host kernel); the qcow2 / AMI / OVA form factor uses the stock distribution kernel for the underlying Debian Trixie or Bookworm base. ### Go applications Go applications using the Go standard library's `crypto/tls` do not route through wolfProvider, regardless of system configuration. Go's standard library crypto (`crypto/tls`, `crypto/x509`, `crypto/aes`, `crypto/sha256`, etc.) is pure-Go and statically compiled into each Go binary; it does not load OpenSSL, libcrypto, or any provider. Installing wolfProvider system-wide does not change this for Go programs. A wolf-go toolchain that transparently routes Go application crypto through wolfCrypt — analogous to Google's BoringCrypto-Go or Microsoft's microsoft/go — is on the wolfSSL roadmap (see FullLinuxFIPS-8ls). No release timeline is committed. A Go SDK (`github.com/wolfSSL/go-wolfssl`) exists for developers who can modify their Go source to call wolfSSL APIs directly in place of `crypto/tls`. It is intentionally **not** included in the FIPS-eval apt repo to avoid conflating the SDK pattern (requires source changes) with the transparent-toolchain story that the rest of the FIPS-eval bundle delivers for C/C++ applications. Customers who want to evaluate the SDK can obtain it directly from the upstream repository. ### Userspace coverage detail The `✓ eval` rows above cover applications that route their cryptography through one of: OpenSSL 3.x (via wolfProvider), GnuTLS (via gnutls-wolfssl), libgcrypt (via libgcrypt-wolfssl), or NSS (via wolfPKCS11). Most userspace cryptographic operations on a Debian Trixie or Bookworm system go through one of these four libraries and are covered transparently. Applications with their own embedded TLS or crypto stacks outside these libraries are not covered by FIPS-eval; the upstream Full Linux FIPS programme handles those cases on a per-application basis during a validated delivery engagement. ### Artifact forms The same package set is consumable in two artifact forms: 1. **Native install via apt or dnf.** Universal across all supported distributions and architectures (Debian Trixie + Bookworm, Fedora 43 + 44, EL 9 + 10, all on both x86_64/amd64 and aarch64/arm64). This is the canonical path; see the per-distro HOWTOs. 2. **Pre-built OCI container images.** Available today for **Debian only** (Trixie and Bookworm, both `linux/amd64` and `linux/arm64`), published at `https://fips-eval.wolfssl.com/oci/` as docker-archive tarballs and multi-arch OCI layout archives. See `HOWTO-oci.md` for the customer recipe. Fedora and EL container images are on the roadmap; in the meantime, Fedora/EL evaluators can build a container locally from the dnf flavor using a two-line `Dockerfile` against the upstream `fedora:43`, `fedora:44`, `rockylinux:9`, `almalinux:9`, `rockylinux:10`, `almalinux:10`, or UBI base image — see the per-distro HOWTO for the exact recipe. The OCI artifacts are not currently pushed to Docker Hub, Amazon ECR Public, or GitHub Container Registry (GHCR). Auth coordination across those three vendor registries is on the roadmap; in the meantime, the artifacts are served directly from the same CloudFront-fronted S3 origin that serves the apt and dnf repositories, fetched via `curl` + `docker load` rather than `docker pull`. ### Known userspace coverage gaps and forward roadmap Two named algorithm gaps in wolfProvider's `EVP_*_fetch(...)` registration table affect specific consumers under this channel. Both are tracked, both are bounded, and one closes on a known wolfSSL roadmap event: **SSKDF (NIST SP 800-56C Single-Step KDF).** wolfProvider does not register an `EVP_KDF` entry point named `"SSKDF"`. This is **deliberate FIPS hygiene**, not engineering oversight: wolfCrypt's `wc_KDA_KDF_onestep` implementation is gated by `WC_KDF_NIST_SP_800_56C`, defined only in non-FIPS builds, and is not inside the wolfCrypt FIPS 5.x / 6.x module boundary covered by CMVP certificates #4718 and #5041. Exposing the entry point today would silently route through a non-validated function, breaking FIPS posture for any consumer relying on wolfProvider for FIPS-validated crypto. SP 800-56C itself is a NIST-approved algorithm — the gap is wolfCrypt-FIPS-boundary scope, not NIST policy. Affected consumers in this channel: - **krb5 PKINIT (certificate-based kinit)**: works — patched at source to use krb5's in-tree `builtin_sskdf`, whose `EVP_MD` digest calls wolfProvider services correctly. - **systemd TPM2 offline-precompute enrollment with ECC device keys**: `systemd-cryptenroll --tpm2-device-key=…` and `systemd-repart` with ECC primaries fail cleanly with a diagnostic when computing the seal offline (no attached TPM). RSA primaries are unaffected (use KBKDF). Online enrollment (TPM attached) is unaffected (TPM hardware performs the seal). Boot-time LUKS unlock is unaffected (TPM hardware performs the unseal). Forward roadmap: wolfSSL's source tree carries the test gate `#if defined(WC_KDF_NIST_SP_800_56C) && (!defined(HAVE_FIPS) || FIPS_VERSION3_GE(7,0,0))` at `wolfcrypt/test/test.c:1532`, the conventional pattern that marks an algorithm intended for the FIPS module at version ≥ 7.0.0. When wolfCrypt FIPS 7.0.0 completes CMVP lab validation, wolfProvider can register a validated SSKDF entry point and both consumer cases close in one change. wolfSSL has not published a CMVP-completion date for FIPS 7.0.0; the forward-promise we can responsibly make is functional (the gap closes when the next wolfCrypt FIPS module ships) rather than time-bound. **ChaCha20-Poly1305 (`EVP_chacha20_poly1305()`).** wolfProvider does not expose ChaCha20-Poly1305 through OpenSSL's `EVP_CIPHER_fetch` namespace. wolfSSL implements ChaCha20-Poly1305 natively, but the provider entry point is not wired in. This is **partly deliberate NIST policy** rather than a pure engineering decision: NIST has not yet added ChaCha20-Poly1305 to the FIPS 140-3 approved-algorithm list, and validated FIPS modules cannot include unapproved algorithms inside their boundary. Affected consumer in this channel: - **OpenSSH**: patched to remove `chacha20-poly1305@openssh.com` from the default cipher offer, leaving AES-GCM and AES-CTR. SSH connections that explicitly negotiate ChaCha20-Poly1305 will fail; modern SSH clients fall back to AES-GCM transparently. Forward roadmap: closure of this gap requires NIST to approve ChaCha20-Poly1305 for FIPS 140-3, which is outside wolfSSL's control. No commitment is or can be made on timing. This is a policy pathway, not an engineering pathway. Internal references: see `patch-characterizations/CHANGE-CATEGORY-ANALYSIS.md` for the full enumeration of patches that survive Mode 2 (4 apps, ~19 lines total) and the category framework. The two algorithm-name gaps above are Category A; the rest are bounded by upstream-side configure-default changes, non-EVP algorithm-name dispatch (SNMPv3 USM, libcryptsetup compile-time defaults), or test-only modifications. ## Artifact attribution The FIPS-eval channel is built on top of upstream Debian, Fedora, and the RHEL family (Rocky Linux, AlmaLinux, CentOS Stream). Upstream mirrors, packages, and trademarks remain the property of the [Debian Project](https://www.debian.org/), the [Fedora Project](https://fedoraproject.org/), the [Rocky Enterprise Software Foundation](https://rockylinux.org/), and the [AlmaLinux OS Foundation](https://almalinux.org/). The FIPS-eval channel adds the wolfSSL FIPS-eval apt and dnf repositories on top of otherwise-stock upstream bases. ## Getting help, support, sales, licensing, and FIPS certification For supported FIPS 140-3 validated wolfCrypt, production licensing, the actual FIPS-certified code, an actual FIPS certificate, and Operational Environment (OE) work to extend that certificate to your specific platform, contact wolfSSL Inc. **Contact wolfSSL:** - Email: - Phone: +1 425 245 8247 - Web: - Products: - FIPS 140-3 information: - Licensing: - Support & Maintenance: **Download the supported, licensed wolfSSL:**