Security-first, first-party Rust, no_std cryptography and secure protocols.
Built in small reviewable releases with strict modern, legacy, and research isolation.

Crates.io | Docs.rs | Release Plan | Threat Model | Security

brynja

Brynja is a security-first, first-party Rust, no_std cryptography and secure-protocol ecosystem. Its first production goal is a serious production-ready TLS and RFC 9580 OpenPGP implementation at 1.0.0; its primitive boundaries are designed so both protocol families and later standalone cryptographic families reuse the exact same reviewed implementations. Cryptography remains Brynja-owned Rust. Narrow encoding and companion-adapter exceptions follow explicit admission and isolation policy.

Development status: Brynja is pre-1.0, incomplete, and not ready to secure application traffic. Every version receives an immutable signed tag only after the required automated checks and green GitHub and CodeQL. Scheduled pentesting and crates.io publication occur at the cumulative checkpoints described below; a tag without a matching committed pentest report was not a scheduled pentest checkpoint.

Cryptography Verification Status

Verification workflow from v0.25.3: implement a component, complete its agreed scoped checks, record the evidence, and close it. Unrelated development does not reopen completed components. The local brynja-verify tracker reports actual executions and input freshness separately; it is not a release gate or certification. Releases follow clean pentest/retest → finite final checks → green GitHub → publication of that same candidate, without restarting verification at upload. See the completion rule and release handoff and transition status.

These tables track concrete public capabilities and the named implementation families in Brynja's active pre-1.0 roadmap. A capability is listed as implemented after its complete public API and functional acceptance checks pass; a planned row is not yet usable. Release qualification and platform-specific assurance are separate from implementation completion. The broader crate-level audit inventory remains available in the component verification status.

✅ Implemented means a named capability is implemented and acceptance-tested; ✅ Fully implemented means every named member of that exact family has a documented, consumer-usable public API and passing functional acceptance. A green implementation status does not mean independently verified. Independent status moves from ❌ to ✅ only when a named independent reviewer signs off and linked evidence identifies the reviewed implementation. The project's own tests, CI, Kani, Miri, sanitizers, fuzzing, differential testing, and pentests do not by themselves constitute independent cryptographic or protocol verification.

Implementation completion does not authorize publication or imply platform qualification.

Modern Hash Functions

Acceleration is separate from portable algorithm completion. Default hash APIs remain portable. Ordinary SHA-2 execution adds default-off complete hash APIs over static and platform-limited hosted authority. Separate hardened SHA-2 execution adds erasing owners and typed secret outputs. Ordinary SHA-3/SHAKE execution connects explicit CPU routes to complete public-data hashing and XOF APIs; its owner retest and native functional collection passed. Further family integration remains planned. The cSHAKE and hosted sponge candidate extends this opt-in public-data surface; its exceptional retest, native collection and full local release verification passed, followed by green GitHub/CodeQL and a signed tag. Separate hardened Keccak execution provides opt-in erasing SHA-3/SHAKE/cSHAKE owners and typed secret outputs. Its owner retest, three-platform native functional evidence and required local release checks passed. These observations do not establish register/spill erasure or universal platform safety. See the acceleration guide for supported routes and deployment requirements. Independent review and FIPS status are separate claims.

SHA-2 covers SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256; SHA-3/SHAKE covers SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256.

Hash family	Implementation status	Owning crate	Independent verification
SHA-2	✅ Fully implemented	brynja-hash-sha2	❌ Not independently verified
General SHA-512/t extension (portable)	✅ Fully implemented	brynja-hash-sha2 (opt-in)	❌ Not independently verified
SHA-3/SHAKE	✅ Fully implemented	brynja-hash-sha3	❌ Not independently verified
TupleHash/TupleHashXOF	✅ Fully implemented	brynja-hash-tuple	❌ Not independently verified
ParallelHash/ParallelHashXOF	✅ Fully implemented	brynja-hash-parallel	❌ Not independently verified
SP 800-185 family	✅ Fully implemented	brynja-hash-sha3, brynja-mac-kmac, brynja-hash-tuple, brynja-hash-parallel	❌ Not independently verified

Modern Message Authentication

The complete KMAC/KMACXOF family here comprises KMAC128, KMAC256, KMACXOF128, and KMACXOF256.

Construction family	Implementation status	Owning crate	Independent verification
KMAC/KMACXOF	✅ Fully implemented	brynja-mac-kmac	❌ Not independently verified
HMAC over modern SHA-2/SHA-3	✅ Fully implemented	brynja-mac-hmac	❌ Not independently verified

HMAC completion covers the ten named SHA-2/SHA-3 identities, streaming and one-shot use, long keys, canonical final-bit messages, protocol-selected byte truncation, mismatch rejection and typed public/secret tags. General SHA-512/t is separately constrained by the modern 128-bit minimum. Protected/resident and accelerated APIs retain their documented target and qualification limits; SIMD HMAC batching and Windows enclave HMAC are not implemented. The v0.25.2 record records the supplied remediation retest and completed project checkpoint; green implementation rows do not authorize publication.

Legacy Hash Functions

Legacy hashes remain outside the modern brynja facade and require an explicit legacy crate dependency even after implementation.

Hash family	Implementation status	Owning crate	Independent verification
SHA-1	✅ Fully implemented	brynja-legacy-sha1	❌ Not independently verified
MD5	✅ Fully implemented	brynja-legacy-md5	❌ Not independently verified

Legacy Message Authentication

Legacy HMAC is explicitly selected for compatibility, outside the modern facade. The v0.25.1 security retest and that tagged release's required checks passed. Hosted owners cover GNU/Linux protected and Apple Silicon resident sessions; the latter do not claim dump exclusion. The completed v0.25.2 checkpoint records project verification, not independent cryptographic certification or authorization to publish.

Construction family	Implementation status	Owning crate	Independent verification
HMAC over legacy MD5/SHA-1	✅ Fully implemented	brynja-legacy-hmac	❌ Not independently verified
Hosted legacy HMAC	✅ Implemented	brynja-legacy-hmac-std	❌ Not independently verified

Protocol And PKI Building Blocks

Capability	Implementation status	Owning crate	Independent verification
TLS and DTLS record-envelope parsing and encoding	✅ Implemented	brynja-protocol	❌ Not independently verified
Bounded DER framing and admitted canonical ASN.1 values	✅ Implemented	brynja-pki	❌ Not independently verified

Security Foundations

Capability	Implementation status	Owning crate	Independent verification
Fixed-width constant-time operations and secret-region lifecycle	✅ Implemented	brynja-core	❌ Not independently verified
Fixed-size secret ownership and explicit sanitization adapter	✅ Implemented	brynja-core, brynja-sanitization	❌ Not independently verified

Official Validation

FIPS validation is a separate official claim from implementation and independent source review. Brynja has no FIPS 140-3 validation, certificate, validated module, approved security policy, or certificate-bound operational-environment claim.

Validation scope	Implementation status	Owning crate	Official validation
FIPS 140-3 cryptographic module	❌ Not implemented	Future brynja-fips-module, brynja-fips	❌ Not FIPS validated

Project Direction

Brynja is building reusable cryptographic primitives, constructions and secure protocols in small, separately selectable Rust crates. Modern APIs are the default; obsolete algorithms and protocols belong to explicit brynja-legacy-* packages. Research and utility algorithms have separate classifications and must not inherit security claims from cryptographic hashes.

The release plan and version plan cover the complete pre-1.0 scope: modern and legacy hashes, MACs, KDFs, ciphers, signatures, PKI, TLS/DTLS, QUIC-TLS, OpenPGP and additional protocol families. Planned scope is not implemented functionality. The tables above show current usable capabilities; current status and release notes track individual milestones.

Each algorithm has one implementation owner. Small family crates can be used without importing the full protocol graph. brynja-crypto remains the composition and policy layer above those primitives; it does not duplicate them. The modern facade does not expose an indiscriminate all-hashes feature.

Usage And Availability

The repository can contain capabilities not yet published on crates.io. Check the crate version matrix before choosing a registry version. The facade README and each leaf crate's README provide usage examples and exact feature requirements.

• SHA-2: named hashes and opt-in general SHA-512/t.
• SHA-3, SHAKE and cSHAKE: fixed and extendable output.
• KMAC, TupleHash, ParallelHash: SP 800-185 constructions.
• Legacy SHA-1 and legacy MD5: isolated compatibility only.

Ordinary hash states are intended for public/unkeyed data and do not promise internal erasure. Use the distinct hardened APIs for secret-bearing input; Brynja clears its owned internal state, while caller-owned inputs and copied outputs remain the caller's responsibility. Registers, compiler-created copies, spills, caches, swap, dumps, aborts and forced termination remain documented limitations—not guarantees that portable Rust can provide.

The separate Windows enclave APIs provide development-tested x64 sessions for modern hashes, MACs and batching through brynja-strict. They are not the Linux host-slice sessions. Hardware/SIMD routes are opt-in; Windows ARM64, production-signed deployment and independent qualification are not claimed. See the conditional cleanup scope before choosing this profile; SDK/OS and whole-process erasure are not guaranteed.

Record framing and bounded DER/ASN.1 values are building blocks, not complete TLS engines or X.509 validation. Brynja must not yet secure network traffic.

Design Boundaries

• Golden rule: cryptographic primitives, constructions, CPU backends and future FIPS module services are first-party Rust. No C/C++ crypto wrappers, OpenSSL, AWS-LC or system cryptographic delegation.
• Production leaves are no_std, with explicit platform interfaces and default-off acceleration. Optional -std adapters stay outside default and bare-metal graphs. Cargo features alone never prove CPU support.
• Modern, legacy and research packages remain isolated. Legacy algorithms do not become safe merely because their implementation is complete.
• No unreviewed third-party dependency enters the core. The optional brynja-sanitization adapter uses exact-pinned sanitization 2.1.1, with default features disabled. Planned base64-ng admission is encoding-only; future rustls/Tokio adapters remain separately selected.
• Source files stay below 500 lines. Hostile inputs, work limits, output failure behavior and secret lifetimes require explicit tests.
• FIPS-aware design is not FIPS validation. Any future validation claim must name the exact certified module and supported operational environment.

See the threat model, cryptography golden rule, unsafe policy and standards policy.

Development Tags And Pentesting

Every development version receives a signed, immutable tag only after its required scoped pentest/retest and local checks, green GitHub/CodeQL and explicit owner approval. Crates.io publication and cumulative checkpoint pentests occur every fifth minor series at its registered final patch—not at each intermediate tag. A scoped development pentest does not automatically reopen completed component verification or launch a repository-wide campaign.

Checkpoint pentests look backwards over the complete delta since the previous public checkpoint, including every intermediate patch and remediation. For example, the next checkpoint covers all changes after 0.20.0 through 0.25.3; the following covers changes after that checkpoint through the registered end of the 0.30.x series. Exceptional pentests remain mandatory for material security-boundary changes and serious findings.

Findings, fixes, retests and residual limitations are recorded in versioned pentest reports. These project assessments do not replace named independent cryptographic review or official FIPS validation. Detailed release-by-release history belongs in those reports and release notes.

Workspace

Package group	Responsibility
brynja	Curated modern facade
brynja-strict	Separate strict-only protected modern sessions; explicit platform limits
brynja-core, brynja-hash-core	Bounded ownership, constant-time and hash interfaces
brynja-hash-*, brynja-mac-*	Reusable algorithm and construction families
brynja-crypto	Cryptographic composition, provider contracts and policy
brynja-crypto-cpu, optional -std adapters	Explicit CPU/SIMD execution boundaries
brynja-protocol, brynja-pki	Record framing and ASN.1/DER building blocks
brynja-tls*, brynja-dtls, brynja-quic-tls	Protocol engine boundaries; complete engines remain planned
brynja-legacy-*	Explicit obsolete-algorithm and protocol compatibility
brynja-sanitization	Separately selected first-party clearing adapter
Future OpenPGP, FIPS and platform-security packages	Separately scoped protocol, validation and deployment work

The crate version matrix lists exact packages, versions and publication status. Each crate has its own README.

Platform Policy

The project targets Linux, Windows, BSD, macOS, Android, iOS and bare-metal no_std. Aesynx remains a future integration target. Portable compilation, native execution and ISA qualification are separate evidence levels. RISC-V instruction results based on QEMU are not native hardware qualification.

Apple Silicon macOS has separate, default-off resident/clearing session APIs for modern hashes, KMAC, TupleHash, batching and ParallelHash, with separately scoped legacy adapters. They require locked guarded storage and joined workers, but do not guarantee core-dump exclusion and are not a fallback for brynja-strict. Native project tests are recorded in the v0.25.2 report; they do not establish dump exclusion or independent cryptographic certification. See the resident profile contract.

Rust Version Support

MSRV is Rust 1.90.0; the default full-check compiler is Rust 1.99.1. The Apple Silicon resident-profile development checks use 1.99.1 too. Historical qualification records retain their original compiler identities; updating the default does not relabel them or qualify new platform support. Release preflight requires the latest stable Rust in the executable compatibility and emitted-code matrices; those checks must still pass. It does not automatically advance the native-evidence compiler or relabel old results. Other tool freshness checks remain unchanged. Kani uses its separately pinned cargo-kani 0.68.0 / Rust 1.90.0 launcher pairing, with Kani's bundled nightly-2026-08-21 verifier compiler. It does not lower the production compiler or make a policy check a proof. See Kani evidence.

Rust toolchain	Required evidence
1.90.0–1.99.0	Workspace all-feature compatibility, public API acceptance, and x86-64 clearing/constant-time codegen checks
1.99.1	Full format, lint, test, platform, policy, docs, package, and security gate

The exact tested compiler versions, including selected patch releases, remain listed in the Rust matrix. Compiler evidence does not imply timing safety or independent verification.

Checks

scripts/checks.sh
scripts/ci/check-rust-version-matrix.sh
scripts/release/release_crates.py --check

The scripts guide groups assurance by component. Focused assurance selects changed implementations and affected consumers, with validated reuse of unchanged results. Routine development tags do not require Miri; crates.io releases require affected-code Miri. Full extended campaigns are explicitly selected assurance checkpoints, not automatic consequences of publication. v0.25.2 retains its full checkpoint. See Miri coverage by release for tested snapshots and pending coverage. Unknown scope stops for review. Long verifier runs stay off ordinary GitHub CI, which retains bounded checks and CodeQL.

License

MIT OR Apache-2.0.

Documentation

• Initial idea and final architecture decision
• Implementation plan
• Release plan
• Version plan
• Threat model
• First-party Rust cryptography golden rule
• Component verification status
• Standards source policy
• Machine-readable standards evidence
• Normative requirement evidence
• Permanent evidence index
• Assurance harness policy
• Kani verifier policy