Wireless File Transfer Security: Encryption Explained

  1. Problem 1: Someone on Your Network Intercepts the Transfer
  2. Problem 2: An Unauthorized Device Connects to Your Server
  3. Problem 3: Your Files Pass Through a Third-Party Server
  4. Problem 4: Public Wi-Fi Exposes Everything
  5. How Different Tools Handle These Problems

Problem 1: Someone on Your Network Intercepts the Transfer

Wi-Fi is radio. Any device in range can capture the packets, and free tools like Wireshark make that easy. On an open network with no password, whatever is inside those packets is readable.

WPA2 and WPA3 encrypt the traffic between each device and the router, so someone outside your network can't read it. People already on the network are a different case. On WPA2-Personal, anyone who knows the password and captures a device's connection handshake can decrypt that device's traffic. WPA3 closes that hole, but a device on the same network can still try ARP spoofing to put itself between two others. An office, a dorm or a shared house all have people who know the password.

Solution: encrypt at the application layer.

If the app encrypts data before it reaches the network, a captured packet is useless without the key. TLS (Transport Layer Security) is the standard way to do this. TLS 1.3 agrees on keys with ephemeral Diffie-Hellman, which gives forward secrecy: traffic recorded today can't be decrypted later, even if the server's long-term private key leaks.

Tools that send everything through a cloud relay get TLS from the relay connection. Tools that stay on the local network have to add encryption themselves, or trust the Wi-Fi to do it.

OpenDrop encrypts file contents itself, on every route: Wi-Fi, peer-to-peer, its own relay, and Bluetooth between Pro phones. The cipher is ChaCha20-Poly1305 (RFC 8439). The key is derived with HKDF-SHA256 from a secret your paired devices share, and encryption runs on the sending device before the bytes leave it. Relay connections also run over TLS, peer-to-peer links use DTLS, and the OpenDrop mobile apps pin your computer's certificate on your local network.

Who holds that secret depends on the plan. On Free, your computer makes it and passes it to your phone through the QR code, and OpenDrop's servers never receive it. On Pro, OpenDrop's account service also stores it, so devices you sign in to your account can join without a QR scan. If you find a security problem, the security and disclosure page explains how to report it.

Problem 2: An Unauthorized Device Connects to Your Server

A file transfer app on your computer usually runs a small server, and anything on the same network can send it requests. With no authentication, a stranger's laptop could list, download or upload files. On a home network with three devices you own, that risk is small. On shared or public Wi-Fi it is not.

Solution: authenticate requests with a shared secret.

The server should only answer devices it trusts. The simple way is a secret both sides know. Sending that secret with each request is a bad idea, because one captured request gives it away. HMAC (hash-based message authentication code) avoids this. The client hashes the request details together with the secret and sends the result. The server repeats the calculation and compares. A captured signed request doesn't reveal the secret.

OpenDrop signs requests between your devices with HMAC-SHA256, using the secret from pairing. Each signature covers the method, path, query, device ID and a timestamp, and expires after 5 minutes, which limits how long a captured request stays usable.

Tip

Because signatures expire after 5 minutes, your devices' clocks need to be roughly right. If your phone's clock is more than 5 minutes off from your computer's, requests can be rejected. Devices that set their time automatically won't run into this.

The QR code is part of this too. It holds the pairing key and the addresses your phone needs to reach your computer, plus a certificate fingerprint so the phone can check it is really your PC. Anyone who scans it can pair with your PC, so don't post or share screenshots of it. More on how that works in QR code pairing for file transfer.

Other tools solve the same problem in their own way, usually with a certificate or an identity check for each device.

Problem 3: Your Files Pass Through a Third-Party Server

Cloud sharing (Google Drive, Dropbox, WeTransfer) works by uploading your file to the provider. It sits on their servers, under their terms, until it is deleted or expires. By default the provider holds the encryption keys, and it can scan uploads for malware or policy violations. Why cloud file sharing isn't always the best option covers the other trade-offs.

Some "direct" transfer tools also need a server in the middle. When two devices can't reach each other (different networks, strict NAT), something has to forward the data. What matters is what that server can see.

Solution: stay on the local network when you can, and encrypt before the relay when you can't.

On the same Wi-Fi there is no reason for the file to leave your network. It goes from phone to router to computer and never touches the internet.

Across networks, a middle hop is sometimes unavoidable. OpenDrop picks either a direct peer-to-peer link or its own relay. Free uses a shared free relay. Pro uses a faster Pro relay with automatic backup. Either way, the relay carries file contents only in encrypted form. It can see transfer details such as file names, folder names, file sizes and device names, which it needs to route the transfer.

That is a different deal from uploading to Dropbox. Dropbox keeps your file in your account until you delete it, and it holds the keys. A relay is there to move a transfer between two of your devices, and it receives the contents already encrypted. It still sees the metadata, so if a file name is itself sensitive, rename the file before you send it.

Problem 4: Public Wi-Fi Exposes Everything

Cafes, airports, hotels and conference venues are the worst case. You don't know who else is connected, and the operator may log traffic. If the network has a password at all, everyone has it. Some guest networks isolate devices from each other; many don't.

Here, a tool that sends plain HTTP between two devices is a real risk: anyone else on the network can capture the file. Authentication keeps strangers from connecting to your server, but it doesn't hide the file contents in transit.

Solution: use a transfer tool that encrypts the payload end to end.

The file should be encrypted before it reaches the network, whatever the network does. OpenDrop does this on every route and has no plaintext fallback: it refuses to send or accept unencrypted file data, and outdated versions are asked to update. Other people on the cafe Wi-Fi can capture the packets, but they can't read the file.

If the network isolates devices, your phone can't reach your computer over the local network. OpenDrop then switches to a peer-to-peer link or its relay, with the same encryption. On Free those remote routes are speed-limited.

End-to-end encryption doesn't hide metadata: which devices are talking and which servers they reach. A VPN hides that from the local network. It doesn't hide file names from the relay, because the relay sits on the far side of the VPN.

How Different Tools Handle These Problems

Every mainstream transfer tool encrypts in transit. The differences are in who can see what, and where the data goes.

AirDrop encrypts the connection between devices. Transfers start nearby over a direct Wi-Fi link with no router needed. On iOS 17.1 and later they can finish over the internet if you move apart. It works between Apple devices, and with select Android phones through Quick Share when the iPhone is set to Everyone for 10 Minutes.

LocalSend encrypts transfers between devices on the same network. It is open source (Apache 2.0) and needs no account. It doesn't work across different networks.

Quick Share encrypts transfers between nearby Android phones and Windows PCs. It is nearby only, so it doesn't cross networks either.

Cloud services (Google Drive, Dropbox, OneDrive) encrypt in transit with TLS and at rest, but by default the provider holds the keys. If the provider must not be able to read a file, encrypt it yourself before you upload it.

OpenDrop encrypts file contents with ChaCha20-Poly1305 on every route (Wi-Fi, peer-to-peer, relay, and Bluetooth between Pro phones), with no plaintext fallback. Requests between your devices are signed with HMAC-SHA256. It works across networks through peer-to-peer or its own relay. File names and sizes are not end-to-end encrypted. On Pro, OpenDrop's account service also holds the key so your signed-in devices can connect.

Pick based on the risk. Family photos on your home Wi-Fi need little, and any of these tools is fine. Sensitive documents on hotel Wi-Fi need payload encryption that doesn't depend on the network. In both cases, don't assume that being on the LAN means being trusted.

Secure Transfers on Your Terms

OpenDrop encrypts file contents with ChaCha20-Poly1305 on Wi-Fi, peer-to-peer, relay and Bluetooth (Pro, phone to phone) transfers, and signs requests between your devices with HMAC-SHA256. There is no plaintext fallback, and Free needs no account.

Download OpenDrop Free