Is Wireless File Transfer Secure? Encryption Explained

Problem 1: Someone on Your Network Intercepts the Transfer

When you send a file over WiFi, the data travels as radio waves. Any device with a WiFi radio in range can, in theory, capture those packets. On an unencrypted network, the contents of those packets are readable. This is called packet sniffing, and it's trivially easy with free tools like Wireshark.

On a WPA2 or WPA3 encrypted network (which is every modern home router), the WiFi traffic itself is encrypted at the link layer. Someone outside your network can't read the packets even if they capture the radio signals. But someone who is already on your network, someone with your WiFi password, can potentially see traffic between other devices on that same network, depending on the router configuration. Shared WiFi at an office, a dorm, or a family home means multiple people on the same network.

Solution: TLS encryption at the application layer.

TLS (Transport Layer Security) encrypts the data before it hits the network. Even if someone on your WiFi captures the packets, they see encrypted gibberish. TLS 1.3 is the current standard. It uses a handshake where both sides agree on encryption keys using ephemeral Diffie-Hellman key exchange, which means even if someone records the encrypted traffic today, they can't decrypt it later if they somehow get the server's private key (this property is called forward secrecy).

File transfer tools that route through cloud services (Cloudflare, AWS, etc.) typically get TLS for free because the cloud infrastructure handles it. Tools that operate purely on the local network have a choice: add TLS themselves (with the overhead of certificate management) or rely on the network's encryption.

OpenDrop takes a hybrid approach. Remote transfers (across different networks) go through Cloudflare tunnels or a Fly.io relay, both of which provide TLS encryption automatically. LAN transfers (same network) use plain HTTP because the traffic never leaves the local network. The reasoning: on your home WiFi, the threat model is different from the public internet. Adding TLS to local transfers would add latency and complexity without meaningfully improving security for the common case of transferring files between your own devices on your own network.

Problem 2: An Unauthorized Device Connects to Your Server

If you run a file transfer server on your machine, anything on the same network could potentially send requests to it. Without authentication, a random device could upload files to your computer or download files from it. On a home network with three trusted devices, this risk is low. On a shared or public network, it's real.

Solution: Request authentication with shared secrets.

Authentication means the server verifies that each request comes from a device it trusts. The simplest method is a shared secret: both devices know a password, and the client includes proof of that password in every request.

Sending the password in plaintext with each request would be a bad idea (anyone capturing a single request would learn the secret). Instead, most implementations use HMAC (Hash-based Message Authentication Code). The client takes the request details (URL, timestamp, body hash), combines them with the shared secret, and computes a cryptographic hash. The server does the same computation and checks if the hashes match. The secret itself is never sent over the wire.

OpenDrop uses HMAC-SHA256 with a 30-second timestamp window. Each request carries a signature computed from the request data and a shared secret that both devices know. If the timestamp is more than 30 seconds old, the request is rejected. This prevents replay attacks (capturing a valid request and resending it later) and makes it impractical to brute-force the secret in real time.

Other tools use different authentication approaches. LocalSend uses self-signed TLS certificates for mutual authentication: each device generates a certificate, and they exchange fingerprints during pairing. AirDrop uses iCloud identity certificates tied to your Apple ID for its "Contacts Only" mode.

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

Cloud-based file sharing (Google Drive, Dropbox, WeTransfer) works by uploading your file to the provider's server. The file sits on their infrastructure, under their control, subject to their terms of service. Most providers scan uploaded files for various purposes: malware detection, content policy enforcement, or in some cases, machine learning training data.

Even tools that claim "direct" transfer sometimes route data through relay servers. If both devices can't connect directly (different networks, NAT barriers), the data needs an intermediary. The question is whether that intermediary stores your data or just passes it through.

Solution: Direct transfer on LAN, pass-through relay for remote.

On a local network, there's no reason for data to leave your network at all. Direct device-to-device transfer over LAN means the file goes from phone to PC through your router and never touches the internet. No third party sees it, stores it, or processes it.

For remote transfers across different networks, some intermediary is unavoidable. The question is what that intermediary does. Cloudflare's tunnel service routes packets between your devices but doesn't store the file data. It's a transport layer, not a storage layer. The tunnel is ephemeral: when you close it, the URL dies and no data persists on Cloudflare's infrastructure.

OpenDrop's Pro relay (Fly.io) works similarly. Data flows as binary WebSocket frames from sender through the relay to receiver. The relay buffers small amounts of data in memory during transit but doesn't write files to disk. When the transfer completes or the connection closes, the data is gone from the relay's memory.

This is fundamentally different from uploading a file to Dropbox. Dropbox stores your file on their servers, indefinitely, until you delete it. A pass-through relay handles your data for milliseconds during transit. The privacy implications are not comparable.

Problem 4: Public WiFi Exposes Everything

Coffee shops, airports, hotels, conference centers. Public WiFi networks are the worst case for file transfer security. Everyone on the network can potentially see everyone else's traffic. The network operator may log traffic. The encryption (if any) uses a shared password that everyone knows.

On a public network, LAN-based file transfer without TLS is genuinely risky. Plain HTTP traffic between your devices can be captured by anyone else on that network. Authentication (HMAC) prevents unauthorized access to your server, but it doesn't encrypt the file contents in transit.

Solution: Use remote transfer mode or a VPN on public networks.

The safest approach on public WiFi is to skip the local network entirely. Use a remote transfer method that encrypts the data with TLS before it hits the local network. With OpenDrop, this means using the Cloudflare tunnel or Fly.io relay even though both devices are technically on the same WiFi. The tunnel encrypts the transfer end-to-end through Cloudflare's infrastructure, so other devices on the public WiFi see only encrypted HTTPS traffic.

A VPN is another option. If both devices are on a VPN, their traffic is encrypted before it reaches the local network. You can then use LAN-mode transfer within the VPN's virtual network.

The worst approach: transferring sensitive files over plain HTTP on public WiFi without TLS or a VPN. If you're on your home network, the risk is minimal (you control who's on the network). On a public network, assume someone is watching.

How Different Tools Handle These Problems

Not all file transfer tools handle security the same way. Here's how common approaches compare.

AirDrop uses TLS 1.2 between devices, even on the local network. Identity verification happens through iCloud certificates in "Contacts Only" mode. The transfer is direct (no cloud relay) and encrypted. The limitation is platform support: Apple devices only.

LocalSend uses self-signed TLS certificates for all transfers, including LAN. Every transfer is encrypted. The trade-off is CPU overhead for local transfers and the need to manage certificate fingerprints for device trust.

Cloud services (Google Drive, Dropbox, OneDrive) encrypt in transit (TLS) and at rest (AES-256, typically). However, the provider holds the encryption keys and can access your files. True privacy requires client-side encryption before upload, which these services don't offer by default.

OpenDrop uses HMAC-SHA256 authentication on all requests, TLS for remote transfers (via Cloudflare/Fly.io), and plain HTTP for LAN transfers where traffic stays local. The design trades LAN encryption for lower overhead, with the assumption that your home network is trusted. On untrusted networks, the remote transfer path provides full TLS encryption.

No approach is universally "best." The right choice depends on your threat model. If you're transferring family photos on your home WiFi, HMAC authentication and local-only traffic are more than sufficient. If you're a journalist handling sensitive documents on a hotel network, you need TLS end-to-end and should treat the local network as hostile. Match the security level to the actual risk, not to an abstract ideal.