Cryptographic foundation
The system uses standard authenticated encryption. No custom primitives.

ChaCha20-Poly1305

All packet encryption uses ChaCha20-Poly1305 AEAD provided by the Python cryptography library. Key derivation uses HMAC-SHA256. No novel cryptographic algorithms are introduced.

Standard library dependency

Cryptographic operations are delegated to the pyca/cryptography library, which wraps OpenSSL and Rust-based implementations. BRY-NFET-SX does not implement its own cipher.

Packet integrity

Packet headers are bound as additional authenticated data. Header tampering, ciphertext modification, and field injection all cause authentication failure and are rejected.

Trust model
How integrity, authenticity, and trust compose in bundle verification.
Field Meaning
integrity_ok SHA-256 manifest hashes match the actual file contents
signature_verified HMAC-SHA256 digest is cryptographically valid
metadata_consistent Key fingerprint derived from actual key material matches between signer and verifier
overall_trusted True only when integrity, signature, and metadata consistency all pass

Unsigned bundles, unchecked signatures, and failed verifications are never reported as trusted. The verification output distinguishes every state explicitly.

Hardening completed
Three internal adversarial security reviews have been run against BRY-NFET-SX. Audit 1 produced 11 findings and was resolved in Phases 35A-35F. Audit 2 produced further findings and was resolved in Phases 38A-38E. Audit 3 produced residual-issue findings that were closed out in a cleanup pass. v0.29.0 added a dogfooding fix discovered during the public challenge work. 258 tests currently pass (220 product tests + 38 tests covering the local Python vault tool that opens V1/V2 browser-produced vaults).

Phase 35A: Provider lockdown

  • DoneFile key provider restricted to configurable root directory
  • DoneEnvironment variable provider restricted to explicit allowlist
  • DoneBundle verification restricted to allowed directory paths

Phase 35B: Nonce safety

  • DoneNonce registry read-check-write protected by exclusive file lock
  • DoneConcurrent strict-mode duplicate nonce attempts correctly serialize

Phase 35C: Trust semantics

  • DoneUnambiguous top-level trust fields in verification output
  • Doneoverall_trusted requires integrity, signature, and metadata consistency

Phase 35D: Storage integrity

  • DoneArtifacts SHA-256 hashed at save time
  • DoneLoad verifies hash against index, rejects tampered files

Phase 35E: Provenance honesty

  • DoneKey fingerprint derived from actual key material at resolution time
  • DoneFingerprint carried through signature records and checked at verification
  • Donekey_version label mismatches exposed without conflating with crypto validity

Phase 35F: Operator trust display

  • DoneExplicit trust verdict banners for all verification states
  • DoneUnsigned exports display warnings, not success messages

Phase 38A: Downgrade resistance

  • DoneSigned records missing key_fingerprint are rejected as metadata-inconsistent
  • DoneLegacy fallback restricted to genuinely unsigned records only
  • DoneCloses the re-sign-and-strip-fingerprint attack path

Phase 38B: Provenance separation

  • DoneEncryption and signer provenance reported as separate objects
  • DoneVerification output no longer conflates key custody between the two

Phase 38C: Index row binding

  • DoneIndex rows HMAC-bound to an auto-generated local secret
  • DoneSecret stored at 0o600 outside the data directory
  • DoneForged index rows cannot be introduced without reading the secret store

Phase 38D: Bundle root lockdown

  • DoneBundle directory resolution rejected under world-writable temp roots
  • DoneVerification refuses paths outside the allowed bundle root

Phase 38E: Artifact envelope limits

  • DoneEnvelope message count limit enforced (default 100, configurable)
  • DoneNon-numeric configuration values fall back to default instead of crashing

v0.29.0: Bundle write canonicalization

  • DoneBundle files written in the same canonical form the manifest hashes
  • DoneExternal verification with standard tools (shasum, sha256sum) now matches the manifest directly
  • DoneDiscovered while dogfooding the public decryption challenge
Current limitations
These are the known boundaries of the current system. They are documented, not hidden.

Local trust model

The system assumes a trusted local execution environment. It is not hardened for hostile multi-tenant deployment or untrusted API exposure.

No KMS or HSM integration

Key material is managed locally via inline, environment variable, or file providers. There is no integration with managed key management services or hardware security modules.

No key lifecycle management

There is no key rotation or revocation mechanism. Key versioning is supported as metadata but lifecycle operations are not automated.

POSIX-only nonce locking

The nonce registry uses fcntl file locking. This is not portable to Windows and is not suitable for network filesystems such as NFS.

Index rows HMAC-bound, file not independently signed

Index rows are HMAC-bound to an auto-generated local secret (Phase 38C), so rows cannot be forged without reading the secret store. The index file as a whole is not independently signed, and an attacker who can read both the data directory and the secret store could still introduce forged entries.

No formal external audit

The internal adversarial review identified and resolved critical issues. A formal third-party security audit has not been conducted.

Assumed environment
The trust boundary assumptions under which the system operates.
  • Trusted local execution environment
  • Operator controls master keys and signer secrets
  • Artifacts are generated and verified within a controlled service boundary
  • Standard Python process and OS-level security assumptions apply
  • The code being executed is the intended, unmodified code

Security questions

For security-specific inquiries, include "Security Review" in the subject line.

Research (not in the product)

NFET-SC-512 candidate primitive

Qira LLC is separately developing a candidate cryptographic primitive called NFET-SC-512 and an AEAD construction called BRY-NFET-AEAD-512. It is a research artifact, not part of this product. It has not been reviewed by any credentialed cryptographer and is not integrated into BRY-NFET-SX. The product above continues to use ChaCha20-Poly1305 exclusively for secrecy.

The spec, reference implementation, 18 pinned test vectors, and a first-pass self-attack report are published for external evaluation at github.com/TheArtOfSound/nfet-primitive. If you are a cryptographer willing to review or attack it, please do — credible findings will be acknowledged publicly.

Research repository (GitHub)