./security_model.md

How We Protect Your Data

Review the cryptography, data flow, browser controls, and trust boundaries behind PingVaults' client-side encryption design.

Browser

Plaintext

Server

Ciphertext Only

Irys

Ciphertext + export

core commitment

You should not have to rely on a privacy promise alone.

In the intended flow, key derivation and encryption happen in your browser.

The vault save API receives ciphertext, salt, IV, and the recovery schema—not your submitted phrase.

An exported backup and offline decryptor reduce dependence on PingVaults staying online.

Confidentiality still depends on deployment integrity, endpoint security, and an unpredictable recovery phrase.

These are auditable design properties, not a guarantee against every threat.

// data_flow[]

Data Flow (Where Your Answers Go)

1
You enter your recovery fieldsIn Browser

Values are handled in the current page during the cryptographic operation and are not included in the vault save request.

2
normalizeInput() standardizes your answersIn Browser

Strips spaces, lowercases, converts full-width characters — so 'Alice' and 'alice' always derive the same key. Runs entirely in the browser.

3
PBKDF2-SHA256 key derivation (600,000 iterations)In Browser

The normalized values are fed through PBKDF2 with a random salt to derive an AES-256 key in the browser.

4
AES-256-GCM encryptionIn Browser

Your vault content is encrypted with the derived key, producing authenticated ciphertext. The app does not intentionally persist the phrase or derived key.

5
Ciphertext sent through the server to ArweaveServer-side

The server receives only ciphertext, salt, IV, and key schema (field types and question text). Answers are never in the request body.

6
Decryption: answers re-derive the key in the browserIn Browser

When reading, ciphertext is downloaded or imported and decrypted in the browser using the re-entered values. No server-side decryption endpoint is used.

// server_access_table[]

What the Vault Save Flow Sends and Omits

✓ Server can see
✗ Not sent in the save request
✓Encrypted ciphertext (unreadable without key)
✗Your passphrase answers
✓Random salt and IV (expected to be public)
✗The derived AES encryption key
✓Key field types (name, custom_question…)
✗Your vault content in plaintext
✓Recovery prompt text
✗The recovery phrase entered in that field
✓Account and contact emails; check-in metadata
✗The derived AES key

// open_source[]

Open Source Policy

📂 pingvaults-crypto ↗

The encryption core, security-critical UI/API snapshots, test vectors, and offline decryptors are published under MIT for inspection and testing.

MIT · crypto.ts · test vectors · offline decryptors

🛡️ Hosted service

Accounts, inactivity checks, reminders and notifications run on PingVaults' hosted service. It handles only ciphertext and the account details it needs; decryption always happens in your browser or in the offline decryptor.

Accounts · Inactivity checks · Notifications

// faq[]

FAQ

Can PingVaults read my vault content?+
The intended flow sends AES-256-GCM ciphertext, salt, IV, and a question schema—not the answers. You can audit the open-source crypto core and inspect the browser's network requests; protect your answers from guessing and endpoint compromise.
What if PingVaults shuts down?+
Yes, if you keep your export. New uploads are stored on Arweave, a public network PingVaults does not control, and the exported JSON includes the ciphertext for the standalone offline decryptor, with no PingVaults account or gateway needed. Keep that export: the salt and IV are not stored on Arweave.
Does the offline decryptor depend on pingvaults.com?+
The downloadable HTML contains its decryption logic and can process an exported metadata file offline. Keep a tested copy with the metadata and recovery instructions.
How can I check for myself that my answers aren't sent?+
Open your browser's developer tools and watch the Network tab while you save a vault. The request contains ciphertext, salt, IV and the question structure, not your answers. The Content Security Policy stops the page from sending data to other sites, the encryption core is open source so you can compare it with the code, and recovery can run entirely in the offline decryptor without our website.
Is the encryption strong enough?+
The implementation uses AES-256-GCM and PBKDF2-SHA256 with 600,000 iterations, plus a fresh random salt and IV. However, an attacker with the ciphertext can test likely phrases offline, so practical protection is limited by the uniqueness and unpredictability of your recovery phrase. Do not rely on names, dates, places, or other discoverable facts.

Documented architecture. Auditable crypto core. Exportable offline recovery.

My Vault →View Verification Page →