Security & transparency

The audit findings register

An independent audit pass reviewed the Python reference core and found six issues, ranging from critical to low severity. Every finding is documented here — not just the ones that made the project look good.

ID	Severity	Title	Status
FC-01	Critical	Forged trap section could destroy any file with zero password knowledge	Fixed
FC-02	Critical	Forged duress section could destroy real data with zero password knowledge	Mitigated — no cryptographic fix exists; level-gated behavior with residual risk documented
FC-03	High	Plaintext could reach disk before ciphertext integrity was checked	Fixed
FC-04	Medium	Key-wipe function didn’t actually wipe memory in CPython	Fixed (documentation — behavior was already out of scope)
FC-05	Low	Package license metadata contradicted the actual AGPL-3.0 source	Fixed
FC-06	Low	Post-quantum secret-key file permission lockdown was a silent no-op on Windows	Fixed

FC-01 and FC-02 are worth reading in plain language, because they show what “we found a critical bug in our own destructive feature” actually looks like:

FC-01 — forged trap section. Decryption used to read the trap configuration from the file header before verifying that header was authentic. An attacker with one moment of write access to a ciphertext file could inject a fake trap requirement into a file that never had one — and the owner’s very next ordinary decrypt attempt would demand codes they never set, destroying the file if they tried to comply, even with the correct password. Fixed: trap fields are now only trusted once the header’s authenticity has been verified using the real password.

FC-02 — forged duress section. The duress-unlock path structurally cannot authenticate the header (that would require the real password, which a duress-password holder never has). That means anyone could construct their own duress data and splice it into any file’s header, triggering a destructive wipe of the real data using a password only they knew. There is no cryptographic fix that preserves duress-password-only unlock — this was checked exhaustively. The mitigation: automatic destructive wipe on duress match is now gated to the paranoid/fortress security levels only; standard/high require an explicit call to trigger it. This is a documented tradeoff, not a complete fix.

Full technical detail — root cause, proof of concept, and fix rationale — is maintained in the project’s audit findings register, public alongside the source at code.fortresscrypt.com.

Threat model: what’s in scope, and what isn’t

A construction is only “secure” relative to a stated threat model. Fortress Crypt’s is public and specific:

Defended against

• Passive ciphertext holders — stolen backups, seized cloud storage, intercepted transfers
• Offline brute-forcers — GPU/ASIC clusters attempting to guess the password, up against 256 MB–4 GB of memory-hard cost per guess
• Tampering — modified ciphertext intended to cause silent corruption or forged decryption
• A future quantum adversary — optional ML-KEM-1024 hybrid mode and 256-bit symmetric keys (~128-bit post-Grover margin)
• Coercion — a duress password that reveals only decoy data (see the precise, deliberately narrow claim below)

Explicitly out of scope — by design, not oversight

• Endpoint compromise. A compromised OS, device, or app exposes the password and plaintext regardless of file-format properties. Fortress assumes a trusted endpoint during operations.
• Weak passwords. No KDF cost survives a guessable password.
• Coercion against the real password. If the holder reveals the real password, everything is exposed. Duress only helps if the duress password is what gets revealed instead.
• Metadata analysis. That a file is a Fortress file, its approximate size, and its timestamps are visible. Per-chunk padding only hides length within a 256–4096 byte window.
• Data loss from the destructive features themselves. Trap and duress are designed to destroy data on the wrong input. A forgotten trap code is gone permanently — that’s intended behavior, not a bug.
• Side channels in underlying cipher libraries beyond Fortress’s own constant-time tag/commitment checks.
• Forward secrecy. There is no key rotation or ratchet. A compromised password compromises every file ever encrypted under it.

The duress claim specifically: after duress activation, the file’s real data and real key commitment are overwritten with random bytes, so the file decrypts only to the decoy from then on. This is a real, verifiable property — not the much stronger (and more commonly oversold) claim that a file can never be proven to contain hidden data at all.