Secrets that evaporate. Not leak.
Client-side encrypted.
Zero-knowledge.
Self-destructing.
- Encrypt. Enter a key and content. The key is derived with PBKDF2-SHA256 (200k iterations). Content is encrypted with AES-256-GCM in the browser. A random IV is generated per secret.
- Store. The server receives a SHA-256 hash of the lookup key and the encrypted blob. Plaintext and encryption key never leave your device.
- Retrieve. Enter the key. The client hashes it, fetches the blob, derives the same key, and decrypts locally. Secrets expire after 24 hours or optionally after first read.
Client-side: key derivation (PBKDF2-SHA256, 200,000 iterations), AES-256-GCM encryption with a cryptographically secure random IV, and lookup key hashing (SHA-256). All operations use the Web Crypto API.
The server stores only the hashed lookup key, the encrypted blob, and expiration metadata. It cannot access plaintext, the encryption key, or the original lookup key.
Authenticated encryption (AES-GCM) ensures integrity: tampering is detected on decryption.
- Hashed lookup key (SHA-256)
- Encrypted blob (AES-256-GCM ciphertext + IV)
- Expiration metadata (TTL or one-time flag)
Protects against: server compromise, database leak, curious admin. The server has no plaintext or keys to expose.
Does not protect against: compromised device, weak or guessable keys, phishing, insecure key sharing (e.g. over unencrypted channels).
- No accounts
- No plaintext storage
- No custom cryptography
- Built on standard primitives (Web Crypto API)
- Minimal attack surface
| Feature | Snappass | Vapor-Locker |
|---|---|---|
| Single-use secret | ||
| Expiration | ||
| Client-side encryption | ||
| Zero-knowledge architecture |
Open source. Rust backend, vanilla JS frontend. github.com/elpideo/vapor-locker