How this service handles encryption, one-time retrieval, storage, and lifecycle.
Two delivery modes cover the main sharing scenarios. Both use AES-256-GCM encryption.
Example for asynchronous delivery: send the link via email and the decryption key via chat.
This service uses browser-side encryption and a lightweight API. The backend stores only three fields per secret: a deterministic ID, the encrypted payload, and an expiration timestamp.
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-256-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 storage ID is derived deterministically from the key as SHA-256(SHA-256(keyBytes)). The backend receives only the encrypted payload, the pre-computed ID, and the TTL. 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 retrieve the ciphertext.
The secret's storage ID is computed as SHA-256(SHA-256(keyBytes)). Since SHA-256 is a one-way function, knowing the ID does not reveal the key, but anyone who holds the key can compute the ID and retrieve the secret. This makes the ID itself the proof of possession, removing the need for a separate authentication header.
The ID space has 256 bits of entropy (derived from a 256-bit key), making brute-force enumeration infeasible.
In real-time mode the link is secret4.eu/#<key>. The key sits in the URL fragment and is never sent to the server, but the single artefact contains all 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 split mode the recipient receives a generic link (secret4.eu/decode) and the key through a separate channel. This reduces interception risk because compromising one channel alone is insufficient to decrypt the secret. 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.