Where we're still hardening
Night Drop is open source and built on audited cryptography libraries, but the app itself
is young. We'd rather you know exactly where it stands than trust a superlative.
Not yet independently audited
The cryptography is built on well-reviewed libraries (the same Double Ratchet family
used by Signal, the Tor project's own Rust implementation, and vetted password and
encryption primitives), and the security-critical code is isolated in a single Rust
core. But the app as a whole has not yet had an independent security audit. Until it
has, we won't claim more than that — and we'll publish the audit and its fixes when it's
done. Treat Night Drop as promising and improving, not battle-tested.
A seized phone still reveals who you talk to
The app lock encrypts your messages. It does not yet cover the file that
holds your own Tor address, or the one folder Tor keeps per contact — each named after
their address. Someone who takes your phone and copies its storage can read that
list without breaking any encryption, and without your PIN.
As of 0.1.15 those entries no longer pile up: deleting a chat removes that person, and
logging out or using the wipe code clears the lot. What remains exposed is the identity
you are using right now, and the contacts you currently have. We are working on moving
those into the encrypted store too; until that ships, assume a seized phone shows who
you have been talking to.
What a relay can still link about your offline messages
Messages sent while you are offline wait on a relay. From 0.1.26 each chat drops them in
its own mailbox, under an address that changes every day, and your phone collects them in
small groups over separate Tor connections, padded with mailboxes that do not exist. So a
relay can no longer tell that messages from different people, or from different days, are
for the same person.
What it can still tell: that messages in one chat on one day belong
together; which mailboxes your phone collects as one group (about seven
contacts at most); that a mailbox checked for weeks and never used is probably padding; and
a burst when you send to several people at once. A chat whose other side runs a version
before 0.1.26 keeps the old, fixed address in both directions until they update, and you
will see a notice in that chat. The limit of 50 contacts is what keeps those groups small;
it is enforced by the app, not the protocol. And offline messages rely on your clock: if it
is wrong by more than three hours, a message can go to a mailbox nobody checks and expire
unread after 24 hours. Messages delivered directly are unaffected.
Bridges beat a blocked relay list. Traffic inspection is tested, not proven.
If your network blocks Tor by blocking the public list of relays, a bridge is an
unlisted way in. If it instead inspects traffic and blocks Tor by how it looks,
that needs a WebTunnel bridge — Tor carried inside ordinary HTTPS
to a normal-looking web server, with a TLS handshake matched to Chrome's.
What we have measured, on our own network: with every route except that one web server
blocked at the router, Night Drop still connected and published its address; with the
bridge removed under the same block, it could not build a single circuit. An
intrusion-detection system carrying 52,311 public signatures, over a thousand of them
for Tor, raised nothing and saw only ordinary TLS.
What we have not done is run it from inside a country that filters this
way. Public tooling is a much weaker adversary than a national firewall, and one thing
is not disguised at all: the shape of the traffic. A connection that pulls tens
of megabytes while sending very little does not look like reading a web page, however
ordinary the handshake is. If being identified as a Tor user is itself dangerous where
you are, do not rely on this alone.
🧪 Real-world Tor testing is ongoing in progress
The full messaging flow is verified end to end in automated tests, and the Tor path
has been exercised over the live network. Broad testing across many real devices,
networks, and conditions is still underway. Expect rough edges on flaky connections.
🛰️ Relay availability in progress
When both people are online, messages go directly, device to device. Offline delivery
and first-contact short codes lean on a relay that holds only sealed, unreadable blobs.
You can add extra relays or run your own, so no single one is a choke point — and
we're expanding the default set for resilience.
🎞️ Opening an attachment in another app in progress
Photos and videos are stored sealed on your device. To play a video in your phone's
built-in player, we briefly write a decrypted copy to an app-private, owner-only
folder — other apps can't read it — and wipe that folder on logout and on the next
launch. While the external player has the file open, and until that cleanup runs, a
decrypted copy exists on disk. Viewing an image in-app never writes plaintext out.
🔮 Long-horizon quantum computing tracked
The part of the encryption that protects message contents already has a strong margin
against future quantum computers. The initial key-agreement handshake is classical
today, like most messengers — there's no live threat, but a well-resourced adversary
could record traffic now to try to decrypt it years from now. Our plan for closing
that gap is documented publicly rather than glossed over.
So what can you count on?
Within those honest limits, Night Drop is designed so that we hold no key to
your messages, keep no logs, and store no account that could be seized or subpoenaed.
Any server only ever sees sealed, unreadable blobs under short-lived, unlinkable handles.
You have no phone number or email tied to your identity, you approve who can reach you,
and your history lives on your device by default. That's the deposit box: sealed,
dropped, and opened by no one in between.
Read the full design and threat model in the open — the
source and documentation spell out every
claim on this page, including these limits.
← Back to Night Drop