echodrop.net

Redacted Server Logs Enabled

About How it works Contact Buy me a coffee

Write once / Read once – one-time notes

Javascript not enabled.

TRUST NO ONE! Use at your own risk.
While significant efforts have been made to secure this application, no
guarantee is given, express or implied, as to its security or suitabilty for your use.

Dead men keep secrets. The living just delay the leak.

EchoDrop is an encrypted, ad-free, private, key separated zero-knowledge (at rest) write-once read-once messaging facility which provides multiple encryption layers, no identifiable logging, no cookies, and a simple interface. It supports both javascript and non-javascript enabled client.

For more detailed information, follow the About link.

Enable dead-drop reply

Read how this works

Dead-drop reply ×

A dead-drop is a one-time reply slot. It is created with the note, as a second ciphertext file. The pickup secret is shown only to you on the next page and is never stored in the clear.

Pickup stays a generic 404 until the recipient submits a reply or explicitly leaves no reply. Opening the note does not seal the slot. If they close the page without submitting, pickup remains 404 until the original note expiry, then the slot is gone.

A submitted reply lasts the same number of days as the original note, counted from the moment it is sent (capped at the site maximum). An explicit “no reply” keeps the original expiry. No mail is sent when a reply is stored.

After the slot is sealed you may open it up to 5 times; then it is destroyed. Pickup does not say how many checks remain.

Checksum and burn-on-early-access apply only to the original note, not to pickup.

Message (max 2048 characters) Notification email (optional)

Send notification to this email on message access. No email is sent if message expires.

Notification subject (max 128)

Valid after (UTC)

^?Valid after

Valid after ×

The note cannot be opened before this date and time. All times are UTC.

Anyone who uses the retrieval link too early and continues past the warning receives a generic 404 Not Found. The server does not indicate that a message exists or will exist later.

If you also enable Burn on early access, that same Continue click destroys the note. Warn the recipient.

All times are UTC.

Expires after (days from valid-after)

365 days max

Burn on early access

^?Burn on early access

Burn on early access ×

This feature will silently burn the note if an attempt is made to read the note before it is valid.

Warn the recipient accordingly.

The note is burned only if they proceed past the Continue prompt. Opening the link without continuing does not destroy it.

Require checksum

^?Require checksum

Require checksum ×

This feature will generate a 6 character checksum which the recipient will be required to enter. Before the message is displayed the checksum will be verified. If it does not match the message will be silently burned.

This checksum should be provided to the recipient via a different mechanism than used to send the URL or token.

Messages are encrypted at rest. The retrieval token is never stored on the server.

About

About echodrop.net

EchoDrop is a write-once, read-once messenger: you write a note, you get one link, the recipient reads it once, then the note is gone. There are no accounts, no ads, and no cookies. The service is designed so the operator cannot read a stored note without the secret that lives in the link (zero-knowledge (at rest)). The server does encrypt and decrypt during create and retrieve.

The retrieval link contains a secret that is never stored on the server. Without that secret, ciphertext on disk cannot be opened—even if a server key is obtained.

Zero-knowledge (at rest) approach

The only secret that can open a note is the token in the retrieval link. That token is never written to disk.
Filenames are one-way derivations of the token. A directory listing does not reveal links, nonces, or tokens.
Schedule (valid after and expiration) lives inside the encrypted payload, not in a sidecar file.
Notification addresses and notification subjects are stored only inside the encrypted payload.
The link uses a URL fragment for the token so browsers do not send it to the web server. Without JavaScript, paste the token into the form; it is submitted in the POST body, not the query string.
Dead-drop (optional). A second ciphertext slot is created with the note. The pickup secret is shown only at create time. Pickup looks like a missing note until the recipient submits a reply or explicitly leaves no reply. Opening the note does not seal the slot. A submitted reply lasts the same number of days as the original note, counted from send time. No mail is sent when a reply is left.

Message protection

Input is length-limited, sanitized, encoded, and padded before it is encrypted. Stored files are padded to a fixed size bucket so length is not visible from the directory.
Authenticated encryption binds a per-message random token to server key material. Tampering is detected and treated as “not found.”
Plaintext is never written to disk. Only ciphertext is stored.
After a successful read, buffers are wiped and the file is overwritten with random data, then removed.
Notes that are already expired when opened are destroyed the same way and still presented as “not found.”
There is no scheduler that must know expiration times so there is no external metadata associated with the message.

Security design and hardening

Fail secure. Permission and path checks run on every request. A failed check stops the application.
Key ring. Server side encryption keys are rotated and retired. Retired keys are kept only until notes that could still use them are past their maximum lifetime, then erased.
Read once. The retrieve page does not decrypt on first view (so automated link scanners do not consume the note). Opening it requires an explicit confirmation. Concurrent openers are serialized so only one request can succeed.
Uniform failure. Missing, expired, not-yet-valid, and forged tokens all produce a generic 404. Retrieve attempts take a minimum amount of time so a fast miss cannot be used to prove a note is absent.
Optional sender controls. Burn on early access destroys a scheduled note if the recipient continues before it is valid. A 6-character checksum, sent by a separate channel, is required when that option is on; a mismatch after Continue silently burns the note. If a checksum wasn't requested at creation time, any checksum input on retrieval is silently ignored. This prevents burning a note due to accidental input.
Logging is off by default. Application diagnostic and usage lines are written only when debug mode is enabled. Debug mode is visually obvious and requires an extra acknowledgement before a note is consumed.
Web server logs. The site tries to detect whether the vhost still writes access or error logs, and shows that status in the header. Site owner can disable those logs at the vhost level.
Abuse controls. Multiple methods of abuse detection and prevention are in place.
Least privilege. Keys, ciphertext, and logs sit outside the web root and are denied by the web server configuration.

What is and is not logged

With debug off, the application does not record that a note was created, expired, or read.
Each request performs a security-assessment and logs that result. No message content, tokens, or addresses are logged.
If you opt in to email notification, a mail server may log the outbound message when the note is actually read, not when it expires.