DSTP/1 — Drop Secure Transfer Protocol

The end-to-end encryption protocol behind every Drop2p transfer. We document it so you can verify what we do — and, in time, so anyone could build a compatible peer.

Design goals

• Confidentiality that survives a compromised or malicious signalling server.
• No trusted third party for key agreement — the code itself authenticates the peers.
• Tamper-evidence on every byte; truncation and replay are detectable.
• Zero storage: keys are ephemeral and nothing is persisted.
• Documented enough to be independently implemented.

At a glance

The transfer, step by step

1. 1

   Code & rendezvous

   A transfer code is channel-secret. The client sends only the channel half to the signalling server to find its peer; the secret half never leaves the two endpoints.

2. 2

   Encrypted transport

   Peers connect over a WebRTC data channel, which is already encrypted with DTLS. Everything below runs inside that channel.

3. 3

   Authenticated key agreement

   Both sides run SPAKE2 (a PAKE, RFC 9382) keyed on the secret half of the code. They arrive at a shared secret only if the codes match — and a compromised signalling server can't substitute its own.

4. 4

   Key derivation

   The PAKE output is expanded with HKDF-SHA-256 into an AES-256-GCM session key. Distinct labels keep purposes separated.

5. 5

   Authenticated records

   Every frame is sealed with AES-256-GCM under a monotonic counter used as the nonce and bound as additional data, so frames can't be reordered, dropped or replayed. A type byte distinguishes metadata, chunk and completion frames.

6. 6

   Encrypted metadata

   The filename and size travel in an encrypted metadata frame — never in the clear, never to the server. For protected transfers it also carries an Argon2id salt and a verifier.

7. 7

   Optional inner layer (double encryption)

   With a passphrase, Argon2id derives a second key and each chunk gets an independent AES-256-GCM seal inside the code-derived one. The receiver verifies the passphrase locally before any bytes flow.

8. 8

   Completion & integrity

   Per-frame tags authenticate every byte; a final size check rejects truncation; and the sender ships a SHA-256 of the whole file in the (encrypted) completion frame, which the receiver recomputes and compares end-to-end. The receiver gets exactly what was sent, or the transfer aborts.

Implementation status

Exactly what the deployed protocol does today. We'd rather under-promise than imply.

Threat model

This page describes the deployed protocol. For the plain-English overview see Security; to try a real DSTP/1 peer in your terminal, see the developer docs.