How we protect your data.

Every vault item is encrypted using AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode) before leaving your device. GCM mode provides both confidentiality and data integrity authentication — if any encrypted byte is tampered with, decryption fails. Each item gets a unique random 96-bit initialization vector (IV). The same plaintext encrypted twice will produce different ciphertext, preventing pattern analysis.

Your master password is never stored. Instead, it's used to derive your encryption key via PBKDF2-HMAC-SHA256 with 600,000 iterations and a per-user random salt. This means an attacker who obtains your encrypted vault data would need to perform 600,000 SHA-256 operations per password guess. On modern hardware, that's roughly 1 guess per second — making brute force computationally infeasible for any reasonably strong master password. The 600K iteration count follows NIST SP 800-132 current guidance (minimum 210,000 for PBKDF2-HMAC-SHA256).

We can't read your data. This isn't a policy — it's an architectural constraint. Your encryption key is derived from your master password, which we never transmit or store. Encrypted vault data is transmitted to our servers, but without the key (which only you have), it is computationally indistinguishable from random noise. The Web Crypto API handles all cryptographic operations in your browser or device. Even Rotorra engineers with full database access cannot decrypt your vault.

Breach checking uses Troy Hunt's HaveIBeenPwned API with the k-anonymity model. Here's how it works: 1. We compute the SHA-1 hash of your password. 2. We send only the first 5 characters (2.5 bytes) of that hash to HIBP. 3. HIBP returns all hashes that start with those 5 characters (~500 results). 4. We check locally whether your full hash is in that list. Your actual password never leaves your device. Not even the full hash.

Vault data is stored in Supabase (PostgreSQL) hosted on AWS in US-East-1. All data is encrypted at rest using AES-256. Connections are TLS 1.3 in transit. Row-Level Security (RLS) policies ensure users can only access their own data — even at the database level, queries from one user cannot return another user's records. Supabase Storage (for documents) uses per-user RLS policies: objects can only be accessed by the user who owns them.

We do not store: • Your master password (never transmitted) • Your encryption keys (derived locally) • Plaintext passwords or vault item contents • Device identifiers or location data • Browser history or usage patterns beyond what's needed for the product We do store: • Your encrypted vault items (AES-256-GCM ciphertext) • The IV and salt for each item (required for decryption — not secret) • Your email address for authentication • Subscription and billing status (via Stripe customer ID)