Loading…
Security
Your files are end-to-end encrypted before they leave your browser and travel directly to your recipient — they never touch our servers. Here's exactly what that protects, how it works, and where the limits are.
File contents, names and types are readable only by the two endpoints — even if our signalling server is compromised or a relay is malicious.
Any tampering, reordering or truncation is detected and aborts the transfer. You get the exact bytes that were sent, or nothing.
Both sides prove they share the transfer code without ever revealing its secret half to our server. A wrong code simply can't decrypt.
Encryption keys are ephemeral — generated per transfer and never stored. There is no master key to leak or subpoena.
No file bytes ever touch our infrastructure. We can't derive your keys or read your files, so there's nothing to breach.
Benefits first; the cryptography underneath, named so you can verify it.
Every connection rides WebRTC's DTLS, which encrypts the channel automatically.
The secret half of your transfer code drives an authenticated key exchange (a PAKE — SPAKE2, RFC 9382) run inside the data channel. The key is derived with HKDF-SHA-256 — and the connection's DTLS fingerprints are folded in, so a server that tries to sit in the middle is detected and the transfer fails closed. Our server never sees the key.
Every frame — including the filename and size metadata — is sealed with AES-256-GCM and a counter nonce, so frames can't be read, reordered or replayed.
On Ultimate, a passphrase adds a second, independent AES-256-GCM layer keyed by Argon2id — applied inside the code-derived layer. Reading the file then needs both the code and the passphrase.
We won't over-claim. Drop2p protects your file contents, not your network identity — your IP address is visible to your peer and to our signalling server. And because transfers are end-to-end encrypted, we genuinely cannot scan or moderate content; abuse is handled through reports, metadata signals and relay controls, never by weakening encryption. And where the protocol has future work, the spec marks it plainly as planned rather than implying it already ships.