How this service handles encryption, one-time retrieval, storage, and lifecycle.
The practical delivery scenarios bloom the create flow. You can select a preset or change to custom.
Example for asynchronous delivery: send link via email and the decryption key via chat.
This service uses browser-side encryption and a lightweight API. The backend stores ciphertext plus one-time metadata only.
The decryption key is generated in the browser using a Cryptographically Secure Pseudo-Random Number Generator provided by the Web Crypto API, and encryption is performed locally with AES-GCM. Each encrypted message uses a random 12-byte initialization vector that is prepended to the ciphertext payload before upload.
When a link contains a decryption key in the URL fragment (after the character #), that fragment is never sent to the server in HTTP requests and remains in the browser.
The backend receives only encrypted payload, expiration, and burn-token hash metadata. Key material never leaves the user device, including during decryption. Read requests use atomic delete-and-return semantics, and after the first successful read the ciphertext is permanently deleted.
Read is atomic with delete, so the system must ensure only someone who already has the decryption key can receive ciphertext.
The burn token is derived by applying SHA-256 to the decryption key bytes, and the client sends it in a dedicated HTTP header during read. The server stores only the SHA-256 hash of that burn token, not the operational token itself, following a double-hash approach similar to password verifiers.
AES-128 has no practical public break and remains strong for normal use.
In a quantum model, Grover-style search can reduce effective AES key strength roughly by half, which leaves AES-128 with a smaller future-proof margin than AES-256. For very short validity windows, such as 15 minutes, AES-128 remains a practical and efficient choice.
For secrets that may remain relevant for days, AES-256 provides a stronger margin.
Embedding the key in the link increases the risk of interception, as one file/artefact contains both the ID and the decryption material.
If an attacker intercepts the link and opens it first, the one-time secret gets used up, and the recipient will be unable to access it afterward, as retrieval is atomic and single-use. If the link is to be intercepted, the secret should be replaced and treated as compromised.
In contrast, split delivery, where the link and key are sent through two distinct channels, reduces the risk of interception of the secret to the link. However, this does not protect against spyware on the sender or receiver's device that can capture both channels.
This web interface requires JavaScript because encryption and decryption are executed locally in the browser. If JavaScript is disabled, the page cannot safely generate or open secrets while preserving the same security model.
Content delivery occurs at BunnyCDN edge locations in Europe and the service components are deployed considering EU data residency.