How a Safety Code Proves You Are Connected to the Right Device
Why encrypted is not the same as authenticated, and how comparing a short code derived from DTLS fingerprints detects a man-in-the-middle.
After a ShareDrop.org connection is established, both screens show a six-digit code. If you read them out and they match, something cryptographically meaningful has been proven: no third party sits between your devices. Here is why that works — and why “encrypted” alone would not be enough.
Encrypted to whom?
WebRTC encrypts every connection (details), but encryption only guarantees privacy with whoever is on the other end. The residual risk is a machine-in-the-middle: an attacker controlling the signaling path could try to establish one encrypted connection with the sender and another with the receiver, decrypting and re-encrypting in between. Both victims see a padlock; neither sees each other.
Fingerprints, and a code built from them
Every WebRTC endpoint has a session certificate whose fingerprint (a hash) is exchanged during negotiation and enforced by the DTLS handshake. The crucial observation: in an attacked connection, each victim negotiates with the attacker's certificate — so the fingerprint pairs on the two sides differ. A safety code exploits this asymmetry:
code = SHA-256( context ‖ sorted(fingerprint_local, fingerprint_remote) ‖ session-id )- Each device computes the code locally, from the fingerprints of the connection it actually negotiated. The server never distributes a “result” — a lying server is the very thing being tested for.
- Sorting the two fingerprints makes both honest devices produce the same input, hence the same code.
- Binding the session identifier prevents replaying a code across sessions.
- Under attack, each side hashes a different fingerprint pair → different codes. Our test suite pins this behaviour with fingerprint-substitution vectors.
Why comparing must happen outside the app
If the app showed you “the other side's code” over the same possibly compromised connection, the attacker would simply relay codes. The comparison only has value over an independent channel: reading it aloud in person, over a phone call, or any medium the attacker does not control. This is the same reasoning behind Signal's safety numbers — the human is the out-of-band channel.
How ShareDrop.org presents it
- Until you confirm a match, the session is labeled identity not verified — transfers work, but the app never claims a verification that did not happen.
- If a connection is rebuilt after a network failure, new certificates mean a new code, and the verified state resets — honesty over convenience.
- Codes differ? Stop, end the session, and re-invite over a trusted channel. See troubleshooting.
What safety codes do not do
A matching code proves the endpoints hold the keys — it does not prove the person at the other endpoint is who you think, and it says nothing about what they do with the file after arrival. It closes the network-level gap; human trust remains yours to establish.
How this is tested
The protocol test suite plays the attacker: it substitutes one side's DTLS certificate fingerprint during connection setup — exactly what a man-in-the-middle relaying two separate encrypted sessions would produce — and asserts that the two devices now derive different safety codes. A matching code with substituted fingerprints would be a broken build; the suite makes that state unshippable. The codes are derived from both endpoints' certificate fingerprints, so neither side can compute the code alone.
Standards referenced
- RFC 8827 — WebRTC Security Architecture: certificate fingerprints, and why signaling is the trust gap that out-of-band comparison closes.
- RFC 8122 — Connection-Oriented Media over TLS in SDP: the
a=fingerprintattribute the codes are anchored to. - NIST FIPS 180-4 — Secure Hash Standard: the hash family used for certificate fingerprints.