Is Peer-to-Peer File Transfer Secure?

The strongest property of a live transfer is what it does not create: a copy of the file sitting in someone else's storage. There is no bucket to misconfigure, no retention policy to read, no provider staff or subpoena with access to the bytes later, and nothing left behind when the recipient forgets to delete a link. For many leaks the stored copy is the whole story, so removing it removes a real class of risk.

The second property comes from WebRTC itself. The WebRTC security architecture (RFC 8827) requires data channels to run over DTLS, so there is no unencrypted mode a careless developer can switch on. Someone on the same café Wi-Fi, the ISP, or a router along the way sees encrypted UDP packets, their sizes and their timing. DTLS also authenticates every record, so a record altered in flight is rejected instead of being delivered.

Those two properties are real, and they are also where the guarantees stop. DTLS encrypts the channel to whichever certificate the other side presented. If the wrong certificate was introduced, the encryption works perfectly and protects the conversation with the wrong party. The stages of a P2P transfer show where that introduction happens: in signaling, before any file data flows.

To connect directly, each peer has to tell the other where it can be reached. ICE candidates carry IP addresses and ports, and a successful direct connection means each side has seen at least one working address of the other. A peer can therefore learn your public IP address, which is enough to estimate your city and your ISP.

Browsers limit how much they reveal. RFC 8828 defines four address-handling modes, from “enumerate all addresses” to “force proxy”, and recommends that without user consent a browser use the default route plus its associated local addresses. In practice that means the public address of the interface your web traffic already uses, not every network adapter on the machine.

VPNs

With a full-tunnel VPN, the default route goes through the tunnel, so the peer sees the VPN's exit address. RFC 8828 singles out split-tunnel VPNs as the main privacy concern: if WebRTC traffic is allowed to bypass the tunnel, the peer can see your ISP address as well as the VPN address. A VPN that blocks UDP may also push the connection onto a relay, which changes who sees your address rather than hiding it.

Relays see addresses too

Forcing traffic through a TURN relay hides your address from the peer, but the TURN provider then sees both addresses, the volume and the timing. It cannot read the file, because DTLS runs end to end between the peers and TURN only forwards the packets. The STUN and TURN explainer covers what each server type learns.

Most P2P tools answer “who is the other peer” with “whoever had the code”. That is three separate questions:

• Admission. Who may join? A session code or link is a shared secret; anyone who sees it over your shoulder or in a chat log can try to use it. Host approval, single-use codes and short expiry all shrink that window.
• Key binding. Is the key I am encrypting to really the key of the person I admitted? In WebRTC the DTLS certificate fingerprints travel inside the SDP offer and answer, through the signaling server. An operator who controls signaling can replace both fingerprints with its own and sit in the middle; both sides still see an encrypted connection.
• Verification. Can the two humans confirm it? Messengers do this with safety numbers or short codes that both people compare out of band. A password-authenticated key exchange (PAKE), as used by Magic Wormhole, binds the key to a short code the server never learns, so a server cannot substitute keys without guessing that code.

The honest framing for most browser tools is that they protect you against the network and against a passive server, and that you trust the signaling operator not to run an active attack. That is the same trust you place in any web app that serves its own JavaScript, but it should be stated, not hidden.

Encryption protects a file on the way; it says nothing about what the file does when opened. A storage service may scan uploads; a direct transfer has no such checkpoint, because no server ever holds the plaintext. If the tool is end-to-end encrypted, no server could scan it even if it wanted to. The receiver is the only place a check can happen.

• Treat a received file like an email attachment from the same person: expected, or suspicious.
• Check that the type matches the name. An invoice.pdf.exe is still an executable, and archives can contain anything.
• For software or datasets, compare a SHA-256 hash the sender gives you through a different channel. Transport integrity (DTLS, AES-GCM tags) proves the bytes were not changed on the way, not that the sender sent the right thing.
• Open untrusted documents in a sandbox or viewer, and let local antivirus scan the Downloads folder as usual.

Tools should also treat file names from a peer as untrusted input: a name like ../../.bashrc must never become a path outside the download folder. The OWASP file upload guidance applies to receivers as much as to servers.

SRIFT does not scan files. Browser transfers are protected by DTLS on the direct path and an authentication tag on every relay chunk, plus a byte-count confirmation at the end, but there is no whole-file hash in browser sessions. AgentNet file transfers between agents do verify a SHA-256 of the complete file.

Every practical P2P tool needs a relay for networks where no direct path opens. How that relay is built decides whether “end-to-end encrypted” survives the fallback.

• TURN relays forward the same DTLS packets the peers would have exchanged directly. The encryption is still end to end.
• Application relays, such as a WebSocket server that forwards chunks, are only end-to-end encrypted if the client seals each chunk before sending, with a key the relay does not have. If the relay connection is merely HTTPS, the relay decrypts TLS and sees the file. This is the distinction drawn in end-to-end encryption vs TLS.

Ask specifically which applies, and whether there is a weaker legacy mode the tool falls back to without telling you.

BitTorrent is also peer to peer, with a very different threat model. A public swarm is open by design: anyone who has the magnet link or finds the torrent can join, and every peer and tracker in it can see the IP addresses of the others. Pieces are checked against hashes, so integrity is strong, but the content itself is not confidential. That is the right design for distributing a public Linux image and the wrong one for a contract.

A private transfer session has two or a few known parties, an admission step, and encryption to those parties only. SRIFT can use WebTorrent, but it is opt-in, and public trackers are a separate opt-in, because WebTorrent seeds unencrypted pieces and a public tracker would let strangers fetch them.

These questions apply to any tool, open source or not. The right-hand column gives SRIFT's answers as of version 4.3.2, including the ones that are not flattering.

For a summary of the product side of this, see encrypted file sharing with SRIFT.