How it works
Last updated: 30 May 2026
A plain-language walkthrough of what happens on your device when you create, unlock, and store assets—written for readers who want to understand the mechanics, not just the marketing claims.
Does my master password ever leave my browser?
No. Your master password is used only inside the browser's Web Crypto API to derive encryption keys. It is never sent to NT² servers, never stored on disk, and never logged.
What encryption does NT² use?
PBKDF2 (100,000 iterations, SHA-256) derives a vault key from your master password and a per-vault salt. Asset payloads and attachments are encrypted with AES-GCM (256-bit key, unique 12-byte IV per encryption). Keys are marked non-extractable so JavaScript cannot export them.
Where is my vault data stored?
On your device: encrypted rows in SQLite (via wa-sqlite → IndexedDB), attachment ciphertext in a per-vault BlobStore, and a small device index for the vault picker. Optional Premium cloud sync (when enabled) stores ciphertext only—never your master password or plaintext items.
Can NT² recover my vault if I forget my password?
No—and that is intentional. Without your master password (or a valid .nt2vault backup you can unlock), the ciphertext cannot be decrypted. NT² has no back door. See Backup & recovery.
The big picture
NT² Vault is local-first and zero-knowledge:
- Local-first — Your vault runs in the browser. Create, search, and edit assets without an account or network connection.
- Zero-knowledge — Sensitive fields are encrypted before they touch disk. NT² operators cannot read your vault contents, even if they wanted to.
Nothing in this design requires you to trust NT² with your secrets. You trust your device, your master password, and standard cryptography.
Create or unlock a vault
When you create or unlock a vault:
- Salt — A random 16-byte salt is read from (or written to) that vault's metadata. The salt is not secret; it ensures the same password produces different keys for different vaults.
- Key derivation — Your master password and salt run through PBKDF2 (100,000 iterations, SHA-256) to derive a vault AES key. Additional keys (for example Vault Key DID signing material) are derived from the same root using HKDF with separate labels.
- Password check — On unlock, NT² decrypts a small known password verifier blob. Wrong password → unlock fails immediately, without exposing item data.
- In-memory keys only — The vault AES key lives in browser memory with
extractable: false. It is cleared when you lock, close the tab, or after idle timeout.
Your master password never leaves the browser sandbox and is never written to SQLite, IndexedDB, or any server.
How each asset is protected
Every vault item has structured fields (title, category, encrypted payload):
| Step | What happens |
|---|---|
| Edit in UI | You type into category-specific fields (bank numbers, mnemonics, etc.). |
| Pack & encrypt | Sensitive fields are JSON-packed and encrypted with AES-GCM using the vault key and a fresh random IV per item. |
| Store | Only Base64 ciphertext + IV (+ non-sensitive title for search) are written to local SQLite. |
| View | Decryption runs in memory only while the vault is unlocked. |
Attachments (PDFs, images) follow the same pattern: encrypted in the browser, ciphertext stored in a per-vault blob store; metadata (filename, size, IV) stays in SQLite.
Copy buttons and clipboard auto-clear reduce accidental leakage after you paste a value— they do not replace locking your vault on shared devices.
Where ciphertext lives on your device
Your browser
├── Device vault index (IndexedDB) → display names + vault IDs for the picker
├── Per-vault SQLite (/nt2-vault-{id}) → encrypted items, metadata, salt, verifier
└── Per-vault BlobStore → encrypted attachment bytes
Each vault is isolated: its own SQLite file, its own attachment store, its own salt. Only one vault can be unlocked at a time.
Export a .nt2vault file to move a vault offline or to another device. The export is encrypted; you still need the master password to import it. Details: Backup & recovery.
Auto-lock and threat model
While unlocked, decryption keys sit in memory. NT² mitigates common risks:
| Risk | Mitigation |
|---|---|
| Walk away from an open laptop | 5-minute idle auto-lock clears keys |
| Tab left open on a shared PC | Lock on tab close / refresh |
| Malicious script trying to steal keys | Keys are non-extractable; cleared on lock |
| Stolen device (vault locked) | Attacker sees ciphertext only at rest |
Auto-lock is a safety net—not a substitute for a strong master password and secure backups. See Security guidelines.
Optional cloud (Premium, when enabled)
Cross-device sync is designed to preserve zero-knowledge:
- The server stores ciphertext blobs and public vault identity (Vault Key DID)—not your master password.
- Authentication uses challenge–response signatures with your vault's key material, not email login.
- PBKDF2 and decryption still run in your browser on each device.
Cloud features are optional. The free tier is a complete local vault with no server dependency.
What NT² deliberately cannot do
These limits follow from zero-knowledge design:
- Reset or recover a forgotten master password
- Decrypt your items on your behalf (including under legal request)
- Prevent you from screenshotting your own unlocked screen
If you need help choosing categories and real-world examples, see Use cases. For privacy policy details, see Data & privacy and Privacy policy.