Trust & Transparency

Security at seQRets

Understanding the threat model, the architecture, and why your secrets are safe.

How seQRets Protects Your Secrets

Zero-Knowledge Architecture

seQRets never sees, stores, or transmits your secret. Everything — encryption, splitting, QR generation — happens locally on your device. There is no server. There is no account. No analytics payload carrying fragments of your data. Your secret enters memory, gets encrypted and split, and is destroyed.

Encryption

Your secret is encrypted with XChaCha20-Poly1305, the same authenticated encryption used in Signal, WireGuard, and libsodium. The key is derived from your password (and optional keyfile) using Argon2id (64MB memory cost, 4 iterations) — the gold standard for resisting brute-force and GPU-based attacks. A generated keyfile adds 256 bits of entropy, defeating brute-force regardless of password strength.

Shamir's Secret Sharing

After encryption, the ciphertext is split using Shamir's Secret Sharing — a mathematically proven threshold scheme. Any fewer shares than the threshold reveals zero information about the original. This isn't obscurity — it's information-theoretic security.

QR Code Output

Each share is rendered as a printable QR code designed to be distributed — stored in separate locations, given to trusted people, or locked in different safes. No single QR code is useful on its own.

Web App vs. Desktop App

Both apps use the same cryptographic core, but the desktop app closes several threat vectors that browsers can't.

ThreatWeb AppDesktop App
Malicious browser extensionsExposed — extensions can read DOM, intercept clipboard, log keystrokesImmune — Tauri's WebView loads no extensions
JavaScript supply-chain attackPossible — code served from CDN at load timeEliminated — bundled, code-signed binary
Memory persistenceJavaScript GC — timing unpredictable, strings immutableRust zeroization — compiler-fence ensures memory is cleared
Binary tamperingN/ADetected — code-signed, integrity verified at install
Offline operationAfter initial load onlyAlways — no network required
Key derivationJavaScript (noble/hashes)Native Rust — argon2, chacha20poly1305 crates
Share integrity verificationSHA-256 hash embedded and verified silently — no visible UIAuto-verified on restore with shield icon, SHA-256 fingerprint on printed cards
Clipboard auto-clear60 seconds after copy60 seconds after copy
Bob AI API key storagelocalStorage (optional "remember")OS keychain (macOS Keychain / Windows Credential Store)
Network exposure indicatorPulsing header dot: red = online, green = offlinePulsing header dot: red = online, green = offline

The web app mitigates supply-chain risk by working offline after the first load. Once cached, no external code is fetched. But for users handling high-value secrets, the desktop app is the recommended choice.

Ready to upgrade?

The desktop app eliminates every browser threat vector.

Native Rust crypto, memory zeroization, code-signed binary — no browser required.

Get the App →

The Seed Phrase Question

"Why does my seed phrase touch a connected device?"

It has to — and the design accounts for it. Your secret briefly enters memory, gets encrypted under a key derived from your password and optional keyfile, is split into Shamir shares, rendered as QR codes, and then destroyed. In the desktop app, Rust zeroes the memory with compiler-fence zeroization. The entire operation takes seconds.

After that, the device holds zero shares and zero copies of your secret. There is nothing left to steal.

"Briefly is all it takes!"

For that brief window to matter, an attacker would need active malware already running on your device — sophisticated enough to read process memory in real time at the exact moment you perform the operation.

If that's your situation, no tool protects you — air-gapped or otherwise:

  • That same malware can keylog your hardware wallet PIN
  • It can screenshot your paper seed when you check it
  • It can modify clipboard contents when you copy an address
  • It can replace firmware on your hardware wallet during updates

The threat model isn't "does the secret touch a device?" It's "is the device compromised at that moment?"

What seQRets actually replaces

Most people aren't using air-gapped machines. They're protecting their seed phrases with:

  • A piece of paper in a desk drawer (fire, theft, single point of failure)
  • A screenshot synced to iCloud or Google Photos
  • A password manager (centralized target, corporate breach risk)
  • A plaintext file called "seed.txt"
  • Nothing at all

seQRets replaces all of that with encrypted, threshold-split backups distributed across multiple locations. Even if one share is physically stolen, it's cryptographically useless without meeting the threshold.

The honest bottom line

An air-gapped machine with a verified OS that never connects to anything is more secure. seQRets doesn't claim otherwise. But for the 99% of crypto holders who don't have that setup, the choice isn't between seQRets and a perfect air-gapped workflow. It's between seQRets and a sticky note.

Frequently Asked Questions

Yes. The full source code is publicly available on GitHub. You can audit the encryption, the splitting logic, and every dependency. There is nothing hidden.
No. There are no analytics, no tracking pixels, no error reporting services. The app makes exactly one optional network call — to fetch the current Bitcoin price for display purposes. That's it. Even that can be disabled by going offline.
Locally on your device only. On the desktop app, the key is stored in the OS keychain (macOS Keychain / Windows Credential Store) rather than localStorage. On the web app, it is kept in localStorage, with an optional "Remember this key" toggle — unchecked, the key is session-only. It is never sent anywhere except directly to Google's Gemini API when you ask Bob a question, and is never included in any other request. You can remove it at any time from the settings.
A keyfile is an optional binary file that acts as a second authentication factor alongside your password. When provided, the keyfile bytes are concatenated with your password before key derivation. A generated keyfile adds 256 bits of entropy, making brute-force attacks infeasible regardless of password strength. It also protects against keyloggers and shoulder surfing since the keyfile is never typed or displayed.
If you encrypted with a keyfile and lose it, your secret cannot be decrypted. There is no recovery mechanism. Back up your keyfile separately from your shares and password — treat it with the same care as any other critical credential.
No. seQRets has no server, no account system, and no backup of your data. If you lose enough shares to fall below your chosen threshold, your secret is gone. This is by design — it means nobody else can recover it either.
Your secrets remain recoverable. We maintain a separate open-source recovery tool called seQRets Recover — one HTML file, no install, no network, works offline in any modern browser. Save a copy of recover.html alongside your Qards and it will keep working long after this website is gone. The recovery tool lives in its own repository (github.com/seQRets/seQRets-Recover) with its own release chain, independent of the main app. The web app and desktop app also work offline once loaded, and the share format is documented well enough that any developer could reimplement the recovery tool from scratch in an afternoon.
Both use the same encryption and splitting logic. The desktop app adds native Rust cryptography, memory zeroization, browser extension immunity, code signing, SHA-256 share integrity verification with visual indicators, and features like the Inheritance Plan builder and JavaCard smart card support.
No. The Inheritance Plan is encrypted and exported as a file or written to a JavaCard. seQRets does not store any copy. If you lose all copies of your encrypted plan, it cannot be recovered.
Web: @noble/ciphers, @noble/hashes, @scure/bip32, and @scure/bip39 by Paul Miller — audited, zero-dependency JavaScript implementations. Shamir splitting uses the shamir-secret-sharing library (independently audited by Cure53 and Zellic). Desktop: native Rust crates — argon2, chacha20poly1305, and zeroize from the RustCrypto project.
Not yet as a whole product by a third-party firm, but the app is built on well-audited primitives: the shamir-secret-sharing library has been independently audited by both Cure53 and Zellic; @noble/* and @scure/* libraries by Paul Miller have undergone extensive public review; and the RustCrypto crates used on the desktop are widely vetted. An internal code review in v1.4.0 identified 11 findings — all resolved. A formal whole-product audit is on the roadmap.
Intentional inversion. For a security app, being online means being exposed to the network — which is the riskier state. Green = offline (safer). The dot pulses red while online and stays solid green while offline. Behind the scenes it pings a tiny (1-byte) file every 5 seconds, because browser navigator.onLine is unreliable.
Yes. Any secret copied from seQRets (password, recovered plaintext, share text) is automatically cleared from the system clipboard 60 seconds after the copy.
Yes. The web app at app.seqrets.app is a Progressive Web App — use your browser's install prompt (or "Add to Home Screen" on mobile) to install it to your device. Once installed, it runs fully offline after first load. For higher-assurance use, install the Desktop app instead: native Rust crypto, explicit memory zeroization, code signing, and an isolated WebView.

Responsible Disclosure

If you discover a security vulnerability in seQRets, please report it privately to security@seqrets.app. Do not open a public issue. We take all reports seriously and will respond within 48 hours.

Upgrade your security

You've seen the difference.
Make the right choice.

The desktop app gives you native Rust cryptography, memory zeroization, and zero browser attack surface. Your secrets deserve it.

Get the App →