Standards Compliance

Overview

dotsecenv aligns with several NIST and IETF standards for cryptographic operations. This page documents two groups.

Compliance standards (how to use cryptographic primitives securely):

• FIPS 140-3: security requirements for cryptographic modules
• FIPS 186-5: Digital Signature Standard (approved algorithms)
• RFC 9580: OpenPGP with mandatory AEAD encryption

Foundational standards (definitions of the primitives themselves):

• FIPS 197: Advanced Encryption Standard (AES)
• FIPS 180-4: Secure Hash Standard (SHA-2 family)

If you deploy in a regulated environment, the rest of this page covers exactly which versions, algorithms, and configurations dotsecenv uses.

---

FIPS 140-3: Cryptographic Module

FIPS 140-3 defines security requirements for cryptographic modules. dotsecenv uses Go’s native FIPS 140-3 cryptographic module, introduced in Go 1.24.

CAVP Validation

The Go Cryptographic Module v1.0.0 holds CAVP certificate A6650, validating the cryptographic algorithm implementations. This certificate confirms that AES, SHA-2, RSA, ECDSA, and other primitives produce correct outputs per NIST test vectors.

Identifier	Description
A6650	CAVP certificate number
v1.0.0	Module version frozen for validation
Geomys	Organization pursuing CMVP certification

The module is currently on the CMVP Modules In Process list with status “Review Pending” and underwent a security audit by Trail of Bits.

Native Go Implementation

This module is built directly into Go’s standard library. It requires no external C dependencies and no cgo bindings. The validated module provides mandatory self-tests for module integrity at startup, an approved deterministic random bit generator (NIST SP 800-90A DRBG), and FIPS-approved implementations for every cryptographic operation.

Build vs. Runtime Environment

FIPS 140-3 validation applies to the runtime Operating Environment, not the build environment. Because Go compiles to standalone, statically-linked binaries with no foreign function interface overhead, the resulting executable is portable and deterministic regardless of where it was compiled.

Our official releases are built on GitHub Actions runners (Ubuntu-based), but the cryptographic operations execute within your deployment environment.

Validated Operating Environments

When you run dotsecenv on a NIST-listed Operating Environment, the Go Cryptographic Module operates in its validated configuration:

Platform	Versions
Red Hat Enterprise Linux	9
Amazon Linux	2023
Oracle Linux	9
SUSE Linux Enterprise Server	15
Alpine Linux	Latest
macOS (Apple Silicon)	11–15
Windows Server	2016–2025
FreeBSD	12–14

The Geomys validation (the organization pursuing FIPS 140-3 certification for Go’s crypto module) also includes Vendor Affirmed coverage for generic Linux 3.10+ on x86-64 and ARM, which gives you broad compatibility across modern Linux distributions.

Module Locking

Setting the GOFIPS140 environment variable during build locks the binary to a specific cryptographic module version:

GOFIPS140=v1.26.0 go build -o dotsecenv ./cmd/dotsecenv

Verify which module version was embedded in any binary:

go version -m ./dotsecenv

Module Version Selection

The version identifier determines which cryptographic module snapshot is embedded:

Build Flag	Behavior
GOFIPS140=v1.26.0	Locks to the module snapshot shipped with Go 1.26.x
GOFIPS140=latest	Uses whatever module ships with your Go version
GOFIPS140=off	Disables FIPS mode (default)

Pinning to a specific version gives you deterministic behavior (reproducible across builds), evidence for auditors (the exact module version is recorded in the binary), and a validated code path (the binary uses the cryptographic implementation derived from the Go FIPS module awarded certificate A6650).

Tip

Without a version pin, GOFIPS140=latest would use whatever module ships with your Go version, potentially code that has not yet been validated. For regulated environments, always specify the version explicitly.

Build It Yourself

dotsecenv is open source, and we encourage security-conscious organizations to fork and build the project on infrastructure under their direct control, whether that is air-gapped systems, internal CI/CD pipelines, or hardened build servers.

Requirement	Value
Go version	1.26 or later
Build flag	GOFIPS140=v1.26.0
Runtime	Listed Operating Environment

---

Cryptographic Primitives

The following standards define the cryptographic algorithms themselves. dotsecenv uses these primitives within the compliance framework established by FIPS 140-3 and FIPS 186-5.

FIPS 197: Advanced Encryption Standard

FIPS 197 defines the AES block cipher algorithm. dotsecenv uses AES-256 exclusively for symmetric encryption of secrets.

Property	Value
Block size	128 bits
Key size	256 bits (AES-256)
Mode	GCM (per NIST SP 800-38D)

Note

While OpenPGP supports AES-128, AES-192, and AES-256, dotsecenv’s RFC 9580 profile negotiates AES-256-GCM for all encryption operations. This provides the strongest symmetric encryption available.

FIPS 180-4: Secure Hash Standard

FIPS 180-4 defines the SHA-2 family of hash functions. dotsecenv uses SHA-256 and SHA-512 for integrity verification and signatures.

Hash	Output Size	Usage in dotsecenv
SHA-256	256 bits	Standard key operations
SHA-512	512 bits	High-strength keys (RSA-4096, ECC P-521)

Adaptive Hash Selection

dotsecenv selects the appropriate hash strength based on key parameters:

Key strength ≥ 256 bits (RSA-4096, ECC P-521) → SHA-512
Key strength < 256 bits (RSA-3072, ECC P-384) → SHA-256

This matches hash strength to key strength, following standard practice.

Hash Usage

SHA-2 hashes serve multiple purposes in dotsecenv:

Purpose	Description
Integrity verification	Detect tampering in vault entries
Digital signatures	Hash-then-sign for identity and secret signatures
Key binding	Link subkeys to primary keys in OpenPGP
Fingerprints	Key identification (transitioning from SHA-1 to SHA-256)

---

FIPS 186-5: Digital Signature Standard

FIPS 186-5 (2023) specifies approved algorithms for digital signatures. dotsecenv enforces these standards for all vault signatures.

Approved Signature Algorithms

Algorithm	Parameters	Status
RSA	2048-bit minimum, 3072-bit recommended	Approved
ECDSA	P-256, P-384, P-521 curves	Approved
EdDSA	Ed25519, Ed448	Approved
DSA	—	Deprecated (removed)

Note

FIPS 186-5 formally deprecates DSA. dotsecenv excludes DSA from approved algorithms and will reject keys using this algorithm.

GPG Algorithm Compatibility

dotsecenv validates GPG key algorithms against FIPS 186-5 requirements. The default configuration enforces:

approved_algorithms:
  - rsa:3072
  - ecdsa:p384
  - eddsa:ed25519

Keys using weaker algorithms are rejected during encryption and signing operations.

Signature Coverage

Every vault entry is signed using a FIPS 186-5 compliant algorithm. The signature covers:

Entry signature covers:
├── Secret key name
├── Available-to list (fingerprints)
├── Encrypted value blob
├── Timestamp
└── Originator fingerprint

Modifying any field causes signature verification to fail:

dotsecenv validate
# ✓ Vault header: valid
# ✓ Identity entries: 2 valid
# ✗ Secret entry 5: signature mismatch
# Error: vault validation failed

Key Strength Requirements

Algorithm	Minimum	Recommended
RSA	2048-bit	3072-bit or 4096-bit
ECDSA	P-256	P-384 or P-521
EdDSA	Ed25519	Ed25519 or Ed448

Caution

For new key generation, use Ed25519 (fast, secure, small signatures) or RSA-4096 (broad compatibility). Avoid P-256 ECDSA for new deployments. P-256 is approved, but Ed25519 has better security properties.

---

RFC 9580: OpenPGP with AEAD

RFC 9580 (2024) is the updated OpenPGP standard, replacing RFC 4880. dotsecenv uses the RFC 9580 profile, which enforces authenticated encryption.

AEAD Encryption

RFC 9580 mandates Authenticated Encryption with Associated Data (AEAD) for all symmetric encryption. dotsecenv uses AES-256-GCM as the symmetric cipher:

// Use RFC9580 profile which enforces AEAD with AES-256-GCM
// RFC 9580 is the updated OpenPGP standard with mandatory AEAD support

Property	Value
Cipher	AES-256
Mode	GCM (Galois/Counter Mode)
Nonce	12 octets (96 bits)
Auth tag	16 octets (128 bits)
Standard	NIST SP 800-38D

Why AES-256-GCM?

GCM mode provides both confidentiality and integrity in a single operation. The 128-bit authentication tag detects tampering, modern CPUs accelerate AES via AES-NI, and GCM allows parallel encryption and decryption. It is also FIPS-approved (NIST SP 800-38D).

Cipher negotiation

OpenPGP performs cipher negotiation based on recipient key preferences. The actual cipher used depends on what the recipient’s public key advertises it supports. RFC 9580-compliant keys must support AES-256-GCM, so messages between modern keys will use it.

Key Differences from RFC 4880

Feature	RFC 4880	RFC 9580
Symmetric encryption	CFB mode	AEAD mandatory
Default cipher	3DES/AES-128	AES-256-GCM
Signatures	RSA, DSA, ECDSA	Ed25519/Ed448 preferred
Key derivation	S2K (simple)	Argon2
Version	v4 keys	v6 keys

Compression and Side-Channel Attacks

dotsecenv explicitly disables compression to prevent CRIME/BREACH-style side-channel attacks:

// Explicitly disable compression per RFC 9580 (avoids CRIME-style side-channel attacks)
encHandle, err := pgp.Encryption().Recipients(recipients).CompressWith(constants.NoCompression).New()

Why disable compression?

When data is compressed before encryption, the ciphertext length varies based on plaintext content. The CRIME attack exploits this in three steps: inject a known string into the plaintext, observe whether the resulting ciphertext got shorter (a duplicate compresses), then iterate to guess secrets character by character.

Compression	Ratio	Speed	Security Risk
BZIP2	Best	Slowest	Length leakage
ZLIB	Good	Fast	Length leakage
ZIP	Good	Fast	Length leakage
Uncompressed	None	Fastest	Safe

Caution

For secrets management, compression provides negligible benefit (secrets are typically small) while introducing a measurable attack surface. dotsecenv uses constants.NoCompression for all encryption operations.

Hybrid Encryption Model

dotsecenv uses hybrid encryption combining symmetric and asymmetric cryptography:

┌─────────────────────────────────────────────────────────────┐
│                     Secret Value                            │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│           Symmetric Encryption (AES-256-GCM)                │
│                                                             │
│   Random session key (256-bit) + Nonce (96-bit)             │
│   → Encrypted data + Authentication tag                     │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│             Asymmetric Encryption (GPG)                     │
│                                                             │
│   Session key encrypted for each recipient's public key     │
│   → One key blob per authorized identity                    │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│            Cryptographic Signature (GPG)                    │
│                                                             │
│   SHA-256/SHA-512 hash signed with originator's key         │
│   → Detached signature for integrity + non-repudiation      │
└─────────────────────────────────────────────────────────────┘

Why hybrid encryption?

Hybrid encryption enables efficient multi-recipient encryption:

Component	Size	Operations per Recipient
Session key	256 bits	Encrypted once per recipient (fast, tiny payload)
Secret data	Variable	Encrypted once total with AES (fast)

For 10 recipients, this means one AES encryption of the full payload plus 10 RSA or ECC encryptions of the 256-bit session key. Without hybrid encryption, you would need 10 full asymmetric encryptions of the entire secret. That is orders of magnitude slower for anything larger than a few bytes.

Encrypted Value Structure

Each secret value blob contains:

┌─────────────────────────────────────────┐
│ Encrypted Value Blob                    │
├─────────────────────────────────────────┤
│ AES-256-GCM nonce (96 bits)            │
│ AES-256-GCM ciphertext                 │
│ AES-256-GCM auth tag (128 bits)        │
│ GPG-encrypted session key (per-user)   │
│ Detached GPG signature (FIPS 186-5)    │
└─────────────────────────────────────────┘

---

Summary

Compliance Standards

These standards specify how to use cryptographic primitives securely:

Standard	Scope	dotsecenv Compliance
FIPS 140-3	Cryptographic modules	Go 1.24+ native module (CAVP A6650)
FIPS 186-5	Digital signatures	RSA, ECDSA, EdDSA; DSA rejected
NIST SP 800-38D	GCM mode	AES-256-GCM for symmetric encryption
RFC 9580	OpenPGP	AEAD mandatory, v6 key support

Foundational Standards

These standards define the cryptographic primitives themselves:

Standard	Defines	dotsecenv Usage
FIPS 197	AES block cipher	AES-256 for symmetric encryption
FIPS 180-4	SHA-2 hash family	SHA-256/SHA-512 for integrity and signatures

Tip

For maximum compliance, build dotsecenv with Go 1.26+ and GOFIPS140=v1.26.0, deploy to a validated Operating Environment, and use Ed25519 or RSA-4096 keys.

See also

• Multi-environment Vaults — pin a FIPS 186-5 policy fragment per machine while keeping separate vaults and identities per environment.
• Security Policies — how approved_algorithms is enforced via /etc/dotsecenv/policy.d/.