What can I use Trusted Vault for?

Future messages like birthday wishes or graduation letters (notes with a release date, delivered after your account has been triggered), time capsules with memories to unlock later, sensitive secrets (end-to-end encrypted), emergency access for crisis situations, life documentation for loved ones, and digital inheritance like passwords, documents, and account access. All of it is delivered only when needed.

How does the dead man's switch work?

You set a check-in period (e.g., 45 days). If you don't check in within that period, the system sends reminder emails (at 30, 37, and 40 days). After the full period without a check-in, your encrypted secrets are automatically released to your trusted contacts who can then decrypt them.

Is my data encrypted?

Secrets are encrypted end-to-end using RSA 4096-bit and AES-256-GCM; only you and your assigned beneficiaries can decrypt them. Notes are encrypted at rest. We do not store plaintext secrets.

What happens if I forget to check in?

You'll receive reminder emails before your check-in period expires. If you don't check in, your secrets will be released to your trusted contacts. However, you can always check in to reset the timer and prevent release.

Can I change my trusted contacts?

Yes, you can add, remove, or modify your trusted contacts at any time. You can also reassign which secrets go to which contacts. Changes take effect immediately.

How secure is the platform?

We use industry-standard encryption: RSA 4096-bit for key pairs, AES-256-GCM for data encryption, and PBKDF2 with 600,000 iterations for password security. Your private key is encrypted with your password before storage, and we do not store plaintext data.

What if my beneficiaries aren't tech-savvy?

The platform is designed to be user-friendly. When secrets are released, beneficiaries receive clear instructions via email on how to access their assigned information. Our support team is also available to help if needed.

Trusted Vault - How Encryption Works

Master Password

Your master password is used only to encrypt and decrypt your RSA private key. We never store your password, only a one-way hash for login. The private key itself is encrypted with a key derived from your password using PBKDF2 with SHA-256 and 600,000 iterations, then stored with AES-256-GCM (authenticated encryption). When you sign up, you can either choose your own password or use a generated 32-character hexadecimal master password (128 bits of entropy) that we show you once.

Key derivation and encryption happen on the server when we generate your key pair (or on the client in the browser when you use the registration API). Either way, the plaintext private key never leaves the device in an unprotected form, only the encrypted private key and your public key are stored.

Recovery Key

The recovery key is a 24-word BIP39 mnemonic phrase (industry standard, e.g. used in cryptocurrency wallets). It is generated only in your browser, we never see it. You are asked to write it down and store it securely. We use it to encrypt a backup of your private key; that encrypted backup is stored on our servers. If you forget your master password, you can recover your account by entering your recovery key: we validate the phrase and return your encrypted backup, and your browser decrypts it with the recovery key to restore access. Because the recovery key never leaves your device in plaintext, we cannot recover your account without it.

Backup encryption uses the same approach as password-based encryption: the recovery phrase is normalized (trim, lowercase, collapse spaces), then a key is derived with PBKDF2 (600,000 iterations) and the backup is encrypted with AES-256-GCM. The format is compatible with our server-side private-key encryption (salt + IV + tag + ciphertext, base64-encoded).

Key Pair Generation

Each account has a 4096-bit RSA key pair. The private key is used only to decrypt the per-secret symmetric keys that we store for you (see Sharing below). The public key is stored in the clear so we can encrypt those symmetric keys for you and for your trusted contacts. Key pairs can be generated on the server at registration (traditional email/password signup) or in the browser via our registration API (e.g. when using the app’s registration or complete-setup flow). In both cases, the private key is immediately encrypted with your master password before storage; the public key is stored as-is.

How Secrets (Content and Files) Are Encrypted

Each secret has its own random 32-byte symmetric key. The secret’s text content and any attached files are encrypted with that key using AES-256-GCM. The symmetric key is never stored in the clear. Instead, it is wrapped (encrypted) once per recipient, including you as the owner, using that recipient’s RSA public key (see Sharing). So we only ever store: encrypted content, encrypted files, and one encrypted copy of the symmetric key per person who can access the secret.

When you create a secret and assign trusted contacts, we create an access grant for each recipient: you (owner) and each chosen contact. Each grant stores the same symmetric key for that secret, encrypted with that recipient’s RSA public key using RSA-OAEP padding. We do not re-encrypt the secret content or files when you add or remove contacts, we only add or remove grant rows. To decrypt a secret, you (or a contact) use your private key to decrypt your grant, recover the symmetric key, then decrypt the content and files.

Flow: Master password → decrypt your private key → use private key to decrypt your access grant → get symmetric key → decrypt content and files.

Changing Your Master Password

When you change your password, we only re-encrypt your private key with the new password. Your secrets and files are unchanged, they are still encrypted with the same per-secret symmetric keys, and those keys are still wrapped with the same public keys in the access grants. So you do not need to re-encrypt any secrets or files; only the private key ciphertext is updated.

Notes (Time-Capsule Messages)

Notes are different from secrets. They are messages you schedule for release to chosen recipients (by email). Note content is encrypted at rest using the application’s encryption (Laravel’s encrypted cast with the server key). They are not part of the end-to-end chain with your RSA key pair. Only secrets (the items you assign to trusted contacts and that are released by the dead man’s switch) use the full chain: your key pair, per-secret symmetric keys, and access grants.

Algorithms in Practice

Server-side: we derive a key from your password with PBKDF2-SHA256, 600,000 iterations, 32-byte salt, then encrypt the private key with AES-256-GCM (12-byte IV, 16-byte tag). Stored format is base64(salt || IV || tag || ciphertext). For sharing, we encrypt each secret’s symmetric key with the recipient’s public key using RSA-OAEP. Client-side: recovery key generation follows BIP39 (entropy + SHA-256 checksum); backup encryption uses the same PBKDF2 and AES-256-GCM parameters. If we publish a separate crypto reference repository, the core client logic for recovery key generation and backup encryption will be available there for you to run and verify.

Private key encryption (server, conceptual)

// Key derivation: PBKDF2-SHA256, 600_000 iterations, 32-byte salt → 32-byte key
// Encryption: AES-256-GCM with 12-byte IV, 16-byte tag
// Output: base64(salt || iv || tag || ciphertext)

Sharing: wrap symmetric key per recipient

// For owner and each trusted contact:
// encrypted_key = RSA-OAEP-encrypt(secret_symmetric_key, recipient_public_key)
// Store one row per recipient in access grants.

Open and Auditable

We publish the core client-side crypto for recovery key generation and private-key backup encryption in a separate repository so you can verify the logic. Server-side algorithms are described on this page and follow the same standards (PBKDF2, AES-256-GCM, RSA-OAEP).

You can run the demo in your browser to verify encrypt and decrypt with your own recovery phrase. Server-side behaviour (key derivation, secret encryption, sharing) is described in the repo’s docs/SERVER_CRYPTO.md.

View the repository (trusted-vault-crypto)

Ready to Preserve What Matters?

Your data is encrypted so only you and your chosen contacts can access it. Get started free.

Get Started Free

How Encryption Works