About Flashpaper

Security Model

Flashpaper is not an end-to-end (E2E) encrypted platform. Our architecture relies on a “trust the server” model. While we use hardened infrastructure and encrypt all secrets at rest, our servers perform the actual encryption and decryption.

If you do not trust Sturdy Statistics to handle your data securely, or if your threat model involves highly resourced adversaries, you should not use this service.

How it works

Unguessable Links

Secrets are identified by random UUIDs. The link acts as the key – do not share it with anyone but the intended recipient. We never index or list secrets.

Encrypted Storage

Text (max 4 KB) and files (max 25 MB) are encrypted in-memory and stored exclusively as ciphertext. The plaintext is never written to disk.

Optional Passphrases

Adding a passphrase provides a second layer of security. We never store passphrases – they are used transiently to derive the encryption key. If you don’t provide one, we use a server-managed key.

Burn after reading

When “Burn after reading” is enabled, Flashpaper enforces a single-attempt policy:

Atomic Locking:

Database transactions guarantee a secret can only be claimed once, even under concurrent access.

Burn on Attempt:

Secrets are destroyed immediately upon the first request. If the wrong passphrase is provided, the secret is still burned to prevent brute-forcing.

Technical Details

Hard Deletion:

Expired or burned secrets are permanently removed from the database and filesystem.

Anti-Caching:

All secret-revealing endpoints enforce cache prevention (Cache-Control: no-store, must-revalidate).

Encryption Primitives:

We use tempel for authenticated encryption and bailey for key lifecycle management. Key material is backed by hardware security (TPM).