QEV (formerly BRY-NFET-SX) is a controlled-use product preview. This page describes the current security posture, the hardening work completed, the trust model, and the limitations that remain open. Where a section is about one specific layer — the Python envelope and bundle platform, or the vault format used by the web, desktop, and CLI apps — it says so, because the two layers do not use the same primitives.
All packet encryption uses ChaCha20-Poly1305 AEAD provided by the pyca/cryptography library, which wraps OpenSSL and Rust-based implementations. Key derivation uses HMAC-SHA256. No novel cryptographic algorithms are introduced and no cipher is implemented in this codebase.
The .vault.json format uses XChaCha20-Poly1305 with an Argon2id-derived wrap key, via libsodium. The KDF parameters travel in the vault header, so they are validated on open rather than trusted: an opslimit or memlimit outside the accepted range (memory 8–256 MiB) makes the open fail with an out-of-range error. A tampered header cannot quietly downgrade the KDF to something cheap to brute-force.
Packet headers are bound as additional authenticated data. Header tampering, ciphertext modification, and field injection all cause authentication failure and are rejected.
| Field | Meaning |
|---|---|
| integrity_ok | SHA-256 manifest hashes match the actual file contents |
| signature_verified | The HMAC-SHA256 authentication tag over the manifest recomputes correctly. Despite the field name, this is shared-secret authentication, not a public-key signature: it proves the tag was produced by someone holding the signer secret, and the verifier holds that same secret. It is not third-party attribution. |
| 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 tags, and failed verifications are never reported as trusted. The verification output distinguishes every state explicitly.
Note the boundary: bundle authenticity rests on HMAC-SHA256, which is symmetric. Anyone holding the signer secret can produce a valid tag, so a bundle tag tells you the bundle came from a holder of that secret — it cannot tell a third party that it came from us. This site's own integrity manifest at /verify is a different mechanism: that one is an Ed25519 public-key signature, and anyone can verify it with the published public key and no secret at all.
The system assumes a trusted local execution environment. It is not hardened for hostile multi-tenant deployment or untrusted API exposure.
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.
There is no key rotation or revocation mechanism. Key versioning is supported as metadata but lifecycle operations are not automated.
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 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.
The internal adversarial review identified and resolved critical issues. A formal third-party security audit has not been conducted.
The desktop installers carry no developer certificate: not notarized by Apple, not Authenticode-signed for Windows. Gatekeeper and SmartScreen will warn you, and they are right to — there is no publisher identity for them to check. The published SHA-256 of each artifact is the substitute, and it is a weaker one: it proves you got the file we published, not that we are who we say we are. The downloads page lists the hashes and explains each warning.
For security-specific inquiries, include "Security Review" in the subject line.
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 QEV. The product above continues to use the ChaCha20-Poly1305 family 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.