Cryptographic Compliance Profiles

Audience: Security Guild, crypto/platform engineers, compliance reviewers, operators deploying into regulated regions. Scope: The cryptographic compliance-profile model — how StellaOps selects region-appropriate hash, HMAC, and password-hashing algorithms by purpose, the certification status of each profile, and the sanctioned interoperability escapes.

Related: Crypto profile configuration (how to select profiles, providers, and simulators) · Password hashing · Trust and signing.

StellaOps selects cryptographic algorithms by purpose rather than by name, resolving each request through the active compliance profile. This lets a single deployment satisfy a regional regulatory baseline (FIPS, eIDAS, GOST, SM, KCMVP) while keeping a fixed set of interoperability escapes for external systems that expect SHA-256.

Overview

StellaOps supports multiple cryptographic compliance profiles to meet regional regulatory requirements:

ProfileStandardRegionUse Case
worldISO/DefaultInternationalDefault profile, uses BLAKE3 for graph hashing
fipsFIPS 140-3US FederalUS government and contractors
gostGOST R 34.11-2012RussiaRussian Federation compliance
smGB/T 32905-2016ChinaChinese national standards
kcmvpKCMVPSouth KoreaKorean cryptographic validation
eidaseIDAS/ETSI TS 119 312European UnionEU digital identity and trust

Certification caveats (current baselines)

Provider identifiers (registry names)

Configuration

The active profile and validation behavior are bound from the Crypto:Compliance configuration section, with an environment-variable override for the profile ID. The profile defaults to world and strict validation is on by default.

Authoritative option shape (section key, env-var names, defaults, strict/warn flags, per-purpose overrides): src/__Libraries/StellaOps.Cryptography/CryptoComplianceOptions.cs.

Hash Algorithm Mapping

Components request hashing by purpose, not by algorithm; the platform resolves the concrete algorithm from the active profile. The purpose set is Graph, Symbol, Content, Merkle, Attestation, Interop, and Secret. The general shape:

Authoritative purpose definitions and the per-profile mapping live in the XML docs of src/__Libraries/StellaOps.Cryptography/HashPurpose.cs (algorithm constants in HashAlgorithms.cs).

HMAC Algorithm Mapping

HMAC uses the same purpose-based selection as hashing. The purposes are Signing (DSSE envelopes, MACs), Authentication (signed URLs, ack tokens), and WebhookInterop. Shape:

Authoritative purpose definitions and the per-profile mapping live in the XML docs of src/__Libraries/StellaOps.Cryptography/HmacPurpose.cs (algorithm constants in HmacAlgorithms.cs).

Simulation paths when hardware is missing

Interoperability Exceptions

Certain operations must use SHA-256 (or HMAC-SHA256) regardless of the active compliance profile to maintain external compatibility. These are the only sanctioned escapes from profile enforcement, and each call site is expected to opt in explicitly via the Interop/WebhookInterop purposes.

Representative exception classes:

Interop call sites are marked in source with [CryptoInteropAllowed] (see src/__Libraries/StellaOps.Cryptography/Interop/), which is the authoritative inventory of exceptions.

Code Usage

Services take a constructor dependency on ICryptoHash or ICryptoHmac and call the *ForPurpose(...) methods, passing a HashPurpose/HmacPurpose constant rather than naming an algorithm. The platform resolves the profile-appropriate algorithm at runtime; Interop/WebhookInterop purposes force SHA-256. HMAC verification uses constant-time comparison.

Interface contracts: src/__Libraries/StellaOps.Cryptography/ICryptoHash.cs and ICryptoHmac.cs. For unit tests, build instances with the DefaultCryptoHash.CreateForTests() / DefaultCryptoHmac.CreateForTests() factory methods (DefaultCryptoHash.cs, DefaultCryptoHmac.cs).

Supported Algorithms

The platform exposes a fixed set of digest, HMAC, and password-hashing primitives, all 256-bit / 32-byte outputs in active use:

The authoritative algorithm-identifier constants live in src/__Libraries/StellaOps.Cryptography/ — HashAlgorithms.cs, HmacAlgorithms.cs, and PasswordHashAlgorithms.cs.

Security Considerations

  1. Algorithm Agility: The purpose-based abstraction allows algorithm upgrades without code changes.

  2. Constant-Time Comparison: All HMAC verification uses CryptographicOperations.FixedTimeEquals() to prevent timing attacks.

  3. Key Derivation: HKDF is used where appropriate for deriving keys from shared secrets.

  4. Interop Safety: External-facing operations are locked to SHA-256/HMAC-SHA256 to prevent protocol confusion.

  5. Profile Isolation: Each deployment uses exactly one profile; mixed-profile operation is not supported.

Testing Cryptographic Randomness

All tests in this repository that assert on cryptographic-randomness output (CSPRNG draws, Shamir share bytes, generated key material) follow the chi-square + Shannon-entropy pattern documented in TESTING_PRACTICES.md “Asserting on randomness”. Equality-based “shares should be different” assertions are forbidden; they have a measurable false-positive rate and produce flaky CI without protecting against real regressions. The reference implementation lives in src/Cryptography/__Tests/StellaOps.Cryptography.Tests/ShamirSecretSharingTests.cs.