Threat Model
Honest Threat Analysis
What seQRets protects against, what it doesn't, and the assumptions the security model depends on. For the narrative discussion, see the Security page.
What seQRets Protects Against
| Threat | How Protected | Confidence |
|---|---|---|
| Physical theft of a single share | Shamir's SSS — one share reveals zero information about the secret | High |
| Fire, flood, or natural disaster | Shares distributed across multiple geographic locations; fireproof case available | High |
| Password manager breach | Secret is never stored in a password manager; protected by independent encryption + splitting | High |
| Cloud provider compromise | Nothing is stored in the cloud; no accounts, no sync, no server | High |
| Brute-force password attack | Argon2id KDF with 64 MB memory cost makes GPU/ASIC attacks prohibitively expensive. Optional keyfile adds up to 256 bits of entropy, making brute-force infeasible regardless of password strength. | High |
| Keylogger / shoulder surfing | Optional keyfile is a binary file — never typed, never displayed. Keystroke capture and visual observation cannot obtain it. | High |
| Physical coercion (with keyfile) | When the keyfile is stored in a separate physical location (e.g., a safe deposit box), the user genuinely cannot decrypt on demand — even under duress. | High |
| Malicious browser extensions (Desktop) | Tauri WebView loads no extensions; isolated execution environment | High |
| Supply-chain JS attack (Desktop) | Code bundled and signed at build time; no CDN dependency at runtime | High |
| Share corruption or tampering | SHA-256 integrity hash embedded in each share; auto-verified at generation and restoration (Desktop shows shield icon, amber warning on mismatch) | High |
| Vendor disappearance / project abandonment | seQRets Recover (github.com/seQRets/seQRets-Recover) is an independent single-file, offline recovery tool that reads the documented share format. Save recover.html alongside your Qards and recovery does not depend on seqrets.app, the company, or the main app continuing to exist. MIT-licensed, mirrorable, built from audited primitives. | High |
| Single point of failure | Threshold splitting means no single entity, location, or device holds the full secret | High |
What seQRets Does NOT Protect Against
| Threat | Why Not | Mitigation |
|---|---|---|
| Compromised device at encryption time | The secret must briefly exist in memory during encryption. Active malware with memory-reading capability could intercept it. | Use a trusted, malware-free device. Desktop app zeroes memory with compiler-fence. |
| Lost threshold of shares | If you lose K or more shares (where K is your threshold), the secret cannot be reconstructed. There is no recovery mechanism. | Choose a conservative threshold (e.g., 3-of-5). Store shares in geographically separate, secure locations. |
| Forgotten password or lost keyfile | The password (and optional keyfile) derive the encryption key. Without them, decryption is impossible. There is no reset or recovery. | Use a strong, memorable password. Back up your keyfile separately from shares. Consider storing a password hint in a different location. |
| Physical coercion (rubber-hose attack) | If an attacker forces you to reveal your password and produce enough shares, the secret is compromised. | Distribute shares to trusted third parties who cannot be coerced simultaneously. |
| Quantum attack after share threshold compromise | If an adversary already holds K or more shares, the scheme has failed and the ciphertext can be reconstructed — a scenario outside seQRets' primary threat model. At that point, XChaCha20-Poly1305's 256-bit key provides ~128-bit post-quantum security against Grover, serving as defense-in-depth. While < K shares are compromised, Shamir's information-theoretic security makes quantum attack impossible regardless of cipher. | Primary mitigation: maintain share distribution so < K are ever compromised (conservative K-of-N, geographically separated storage). Secondary: use a strong password to harden the defense-in-depth layer. |
| Malicious browser extensions (Web app) | Extensions can read DOM, intercept clipboard, and log keystrokes in the browser context. | Use the Desktop app for high-value secrets. Or use a dedicated browser profile with no extensions. |
| JavaScript memory persistence (Web app) | JavaScript's garbage collector does not guarantee when or if memory is zeroed. Immutable strings cannot be overwritten. | Use the Desktop app (Rust zeroization). The web app mitigates by minimizing secret lifetime in memory. |
Security Assumptions
The seQRets security model holds when the following assumptions are true:
- The device is not compromised at the moment of encryption/decryption. No active keylogger, screen capture, or memory-reading malware is running.
- The password is strong and not reused from other services. Argon2id makes brute-force expensive, but a weak password still weakens the system. Using the optional keyfile mitigates this — a generated 256-bit keyfile makes brute-force infeasible regardless of password strength.
- The keyfile (if used) is backed up securely and stored separately from shares and passwords. Keyfile loss is irrecoverable — there is no reset mechanism. Store copies in multiple secure locations.
- Shares are stored securely in separate locations. The threshold model only works if an attacker cannot access K shares.
- The cryptographic primitives are secure. XChaCha20-Poly1305 and Argon2id are well-studied and widely deployed. A break in either would affect the broader security ecosystem, not just seQRets.
- The source code matches the running binary. For the desktop app, code signing provides this guarantee. For the web app, this depends on the hosting infrastructure.
Comparison to Alternatives
| Method | Single Point of Failure | Fire/Flood Risk | Theft Risk | Inheritance Ready |
|---|---|---|---|---|
| Paper backup | Yes | High | High | No |
| Metal seed plate | Yes | Low | High | No |
| Password manager | Yes (vendor) | Low | Medium (breach) | Depends |
| Hardware wallet seed | Yes | High (paper backup) | High (paper backup) | No |
| seQRets (Shamir split) | No (threshold) | Low (distributed) | Low (per share) | Yes |
Known Limitations
No third-party audit yet
The code is open source and uses audited primitives, but seQRets itself has not undergone a formal third-party security audit. This is on the roadmap.
Web app browser risks
Browser extensions, JavaScript supply-chain attacks, and unpredictable garbage collection are inherent risks of running in a browser. The desktop app eliminates these.
JavaScript memory model
In the web app, JavaScript strings are immutable and cannot be explicitly zeroed. The GC will eventually reclaim the memory, but timing is unpredictable. The desktop app uses Rust's zeroize crate with compiler-fence.
QR code durability
Printed QR codes can fade, get damaged, or become unreadable over time. Use high-quality printing, protective sleeves, or write shares to smart cards for long-term storage.