How NetXfer works

In one paragraph

NetXfer moves a file from one computer to another over an encrypted link, without parking it on anyone's server. The sender picks a file; NetXfer produces a short block of text called the transfer packet. The sender passes that text to the receiver over any channel they trust. The receiver pastes it into NetXfer, and the two apps connect, directly if they can, through a rendezvous if a firewall is in the way, and in version 2.0 through an end-to-end encrypted relay if nothing else works. Every byte is AES-256 encrypted with a key that only the two apps hold.

The transfer packet

The packet is everything the receiver needs to find the sender and decrypt the file. It is plain text, so it survives being pasted into a chat, an email or a ticket, and it can also be saved as an .xfer file and dropped onto the receiving app. Decoded, it holds six lines:

• the sender's public IP address,
• the sender's local IP address, so two machines on the same network connect without leaving it,
• a random 16 character file id,
• a random 24 character encryption phrase,
• the file size,
• the sender's listening port and its rendezvous port.

The packet never goes to netxfer.com. When the server is used at all, the apps send it a separate server key derived from the id and the phrase with a one-way hash, and the server stores only a hash of that. The server can recognise a legitimate request without ever being able to reconstruct the phrase.

SRT and AES-256

Version 2.0 moves the transport to SRT, Secure Reliable Transport, in file mode. SRT runs over UDP, which is why NetXfer fills the bandwidth you have instead of collapsing on a lossy or high latency link, and it has its own retransmission, pacing and congestion control built for exactly that environment. Drastic uses the same stack to move live video for broadcasters, so it has been through its share of bad hotel wifi.

Encryption is part of the SRT handshake and is always on:

• The encryption phrase from the packet is the SRT passphrase, and the cipher is AES-256.
• The receiver puts the file id in the SRT stream id, so the sender's listener knows which passphrase to expect before the handshake completes.
• A connection for an unknown id, or with the wrong passphrase, is rejected by SRT itself. No file data is exchanged, and nothing about the file is revealed.

After the handshake the two apps exchange the file name, size and modification time, the receiver says how much it already has, and the sender streams the rest. There is no option to turn encryption off, in the free or the commercial version.

Three ways to connect

The receiver works down a short ladder and stops at the first rung that connects. Each reconnect, for whatever reason, starts the ladder again from the top, so a transfer that began over a relay will switch back to a direct link if one becomes possible.

1. Direct

The receiver tries the sender's local address, then its public address, on the listening port from the packet. If either answers, the transfer starts immediately. This is the path for two machines in the same office, a laptop sending to a server with a public address, or any sender whose router forwards the NetXfer port. Nothing but the two computers is involved, and netxfer.com sees nothing at all.

2. Rendezvous

Most home and office machines sit behind NAT or a firewall and cannot be reached from outside. The rendezvous mode gets two such machines talking directly anyway, using a technique usually called UDP hole punching: each side sends to the other's public address and port at about the same time, and both firewalls see the traffic as a reply to something their own machine started.

For that to work, each side needs the other's current addresses. That is the one job of the rendezvous server, netxfer.com by default, or your own server with a commercial licence:

1. The sender registers. While a file is being shared, the sending app keeps a small record on the server under the random file id: its local and public addresses, its listening and rendezvous ports, the file name, size and modification time, and whether it allows a relay. The request carries the server key, and the server stores only a hash of it.
2. The sender passes the packet to the receiver over whatever secure channel they like. The server is not involved in this step.
3. The receiver fails to connect directly and publishes its own local and public address and its rendezvous port to the same record, proving it holds the packet by presenting the same key.
4. The sender sees the receiver's addresses on its next heartbeat and both sides start punching towards each other. The SRT handshake, with the passphrase, completes directly between the two apps.
5. The file flows computer to computer. Encrypted, exactly as in a direct connection. The server has already done its job.

The sender removes the record when it stops sharing the file. Advanced users who would rather not touch netxfer.com at all can untick Use a rendezvous server in Preferences; NetXfer then makes direct connections only.

3. Encrypted relay New in 2.0

Some networks defeat hole punching: symmetric NAT, carrier grade NAT on mobile connections, corporate firewalls that allow only web traffic out. Before 2.0 a transfer between two such networks could not happen. The relay is the answer, and it was designed so that adding a server to the path adds no one who can read the file.

If direct and rendezvous attempts both fail, and the sender, the receiver and the server all allow it, the receiver asks the server to start a relay. From then on:

1. The sender seals the file in chunks. The sending app cuts the file into 8 MB chunks and encrypts each one with AES-256-GCM. The key is derived from the encryption phrase and the file id with PBKDF2-HMAC-SHA256 (200,000 rounds), so it is different from the SRT key and still something only the two apps can compute. The file id, size, modification time and the chunk's index are bound into the encryption as authenticated data.
2. Chunks go up over HTTPS. The server checks a checksum of the sealed bytes and stores them in a directory outside its web root. The sender is allowed to run a few chunks ahead of the receiver, 8 by default, so a relay never holds more than about 64 MB of ciphertext at a time, however large the file.
3. The receiver pulls each chunk down. It fetches the chunk over HTTPS, checks the checksum, opens it with the key it derived itself, and writes it to disk. Because the chunk index and the file details are authenticated, a chunk that was altered, replaced with another chunk, or served out of order fails to open and is rejected.
4. The server deletes each chunk as soon as the receiver has fetched it. When the transfer ends, nothing is left. There is no stored copy to download later, which is also why the sender must stay online for the whole relay.

The relay is opt-in at every level. The sender's Allow relay downloads through the server preference is on by default and can be turned off per installation. The receiver can decline relays too. A self-hosted server can leave the relay disabled, in which case the apps simply stop at the rendezvous rung.

Resume and verification

Every receiving session begins with the receiver telling the sender how many bytes it already has on disk, and the sender continuing from there. The partially written file carries a small side record of the name, size and modification time it belongs to, so a resume is only attempted against the same file. The practical result:

• A dropped connection costs you the reconnect, not the download.
• Closing the app, or the laptop, and opening it again later picks up where it stopped.
• A transfer that started over a relay and later finds a direct path simply continues over the faster link.

With Validate with MD5 turned on, the receiver asks the sender for the file's MD5 once everything is written and compares it with its own. Relay chunks are additionally checksummed in transit, over the encrypted bytes, so a damaged chunk is re-sent rather than written.

What netxfer.com stores

When the rendezvous server is enabled, this is the complete list of what it holds for one shared file:

Not stored, ever: the encryption phrase, the transfer packet, or any readable part of your file. Thirty failed key checks from one address in ten minutes block that address for a while, so the id and key cannot be guessed, and expired records, tickets and relay files are swept automatically. The app may also ask netxfer.com for its public IP address, the same way a "what is my IP" site works; that request carries nothing but the request.

Compared with the alternatives

There are many ways to move a large file. Most of them involve a copy sitting on somebody else's machine for a while, and most of the risk lives in that copy.

File servers and cloud services have their place, especially when many people need the same file for a long time. When the file is sensitive, large, or both, and it needs to get from one person to another, NetXfer is the shorter and safer path.

A workflow example

A digital imaging technician on location needs to get the day's rushes to the post facility overnight. The DIT machine runs NetXfer with a folder of camera files queued; the facility runs NetXfer, or a Net-X-Code Server, on its ingest machine. Each file's packet goes to the facility over the production's messaging tool. The ingest machine pulls every file directly, saturating whatever uplink the location has, and because SRT recovers lost packets without stalling, a flaky satellite or cellular link is used to its full capacity. If the hotel network blocks UDP, the transfers fall back to the encrypted relay rather than failing. With MD5 validation on, the editor's copy is proven identical to the camera original, and nothing was ever stored in between.

Running your own server

Everything netxfer.com does, a commercial customer can do on their own domain: the rendezvous and relay server is a small PHP application with a database, it runs behind any standard web server, and the apps point at it through the Custom Domain field in Preferences. The relay directory, chunk size, window and concurrency are configurable, the relay can be disabled outright, and the server can sit behind your own reverse proxy. The security model is identical: your server stores hashes, addresses and sealed chunks, and never the key.

See the business page for licensing, or write to sales@drastictech.com.