About Flashpaper

Flashpaper is a one-time secret sharing tool designed for high confidentiality. We store ciphertext only, burn secrets on the first access attempt, and enforce strict no-cache policies.

How it works

IDs
Each secret is given a random UUID which is not guessable and which reveals nothing about the secret. The ID is the key; do not share it with anyone but the intended recipient. We do not list or index secrets anywhere.
Text secrets
Your text is encrypted immediately in memory (server-side) and stored as ciphertext in the database (max 4 KB). The plaintext is never written to disk.
File secrets
Files are streamed through an encryption layer before being written to disk. The plaintext file is encrypted in-memory and is never written to disk (max 25 MB).
Passphrase (optional)
You may add a passphrase for a second layer of security. We do not store your passphrase; we use it to derive the encryption key. Without it, the secret is mathematically unrecoverable, even by us.
Server-managed key (no passphrase)
If no passphrase is provided, we encrypt with a server-managed symmetric key.

Burn after reading

When “Burn after reading” is on, Flashpaper enforces a strict single-attempt policy.

  • Atomic Locking: We use database transactions to ensure a secret can only be claimed once, even if requested simultaneously by multiple users.
  • Burn on Attempt: The secret is deleted as soon as it is requested. If a user (or bot) accesses the link but provides the wrong passphrase, the secret is destroyed to prevent brute-force attacks.

Technical Details

Lifecycle

  • Every secret has a TTL. Expired secrets are purged automatically and cannot be recovered.
  • Deletion is a hard delete: database rows are removed and encrypted files are unlinked from the filesystem.

Transport & caching

  • All secret-revealing endpoints send Cache-Control: no-store, must-revalidate.
  • We enforce Referrer-Policy: no-referrer to prevent leaking IDs to third parties.
  • Secret URLs are unguessable (UUIDs) and aren’t listed anywhere.

Encryption

  • We use tempel for authenticated encryption and bailey to manage the key lifecycle.
  • Key material is managed server-side, backed by hardware security (TPM).

Policy

What we store

  • Never the plaintext secret.
  • For text: encrypted bytes (ciphertext) ≤ 4KB.
  • For files: path to the ciphertext on disk, original filename, size.
  • Operational metadata needed to run the service (timestamps, IDs, TTL, and burn flag).

What we don’t do

  • No indexing or previewing your files.
  • No embedding third-party trackers on secret pages.
  • No storing passphrases.

Security Model

Trust

Flashpaper is a Server-Side Encryption service. You trust this server to perform the encryption and deletion as described. It is not an end-to-end encrypted system (like Signal); the server possesses the keys to decrypt secrets that do not use a passphrase.

Threat Model

  • Compromised Link: If an attacker intercepts the link, they can view (and destroy) the secret. Use a passphrase to mitigate this.
  • Server Seizure: If the server is seized while running, secrets in memory could be exposed. Secrets on disk are encrypted.
  • Availability: We prioritize confidentiality over availability. If the service is under heavy load or attack, we may fail closed.

Policy

Do not use Flashpaper for content prohibited by law or our Terms of Service.

Questions? Reach out to the Sturdy Stats security team.

Send a secret