A Privacy Box for Every Device: The Portable Tor Router

Press Next hop to follow a request from the router to the website. The rings around the dot are the layers of encryption: the router adds three, and each relay can remove only one. The first relay learns who sent the request but not where it goes; the last relay learns where it goes but not who sent it. Switch the website to HTTPS and the final step stays scrambled too. The scrambling here is real encryption, done in your browser.

Each row is the data on the wire between two stops. Watch the byte count: every layer starts with one short line, “NEXT” and an address, so the bundle shrinks by that line at each relay. A relay that tries the wrong key gets nonsense and no address, which is why only the right relay can open each layer. Change one letter of the message and watch the scrambled rows: only the matching characters change. Counter-mode encryption hides what the letters are but not where an edit happened, which is one reason real Tor adds a tamper check to every cell.

The router holds a 128-bit key and counter for each relay and encrypts inside out: exit layer first (the destination and request), then the middle layer (the exit’s address and that ciphertext), then the entry layer. Counter mode turns AES into a keystream, so ciphertext length equals plaintext length and decryption is the same operation as encryption. The hex rows show the first 24 bytes of each stage; the key line shows the active relay’s key and the header it recovers. Real Tor differs in two ways the note under the demo names: keys come from a key exchange with each relay, and data travel in fixed-size cells so lengths reveal less.

The demo follows the paper’s description of onion routing in Section II-B (layer k readable only by node k, each node knowing only its predecessor and successor) rather than Tor’s circuit protocol, where the path is built once with telescoping handshakes and later cells carry no routing header. The construction makes the paper’s claims concrete: the entry relay sees the router’s address and ciphertext, the middle relay sees two relay addresses, and the exit relay sees the destination and, without end-to-end encryption, the request. Length is the one property the page’s onion leaks at every hop; Tor’s fixed 514-byte cells close most of that channel.

Turn the Tor router off and your Internet provider can see every website you visit. Turn it on and the provider sees only that you are using Tor. Notice the two rows that stay “Yes” either way: anyone else on the router’s own Wi-Fi, and (without HTTPS) the exit relay, which can read what you send. The paper names both and recommends using the Tor Browser and HTTPS along with the router.

Before a browser can load a page it asks a DNS server for the site’s numeric address, and that question names the site. If those questions skip Tor, an observer learns where you are going even though the pages themselves are hidden; this is a DNS leak. Turn DNS through Tor off to see the leak. The authors ran a leak test on their router and found none: the lookups went through Tor.

Each row restates a sentence of the paper. Off: the upstream network reads source, destination, and timing from packet headers. On: the ISP sees encrypted traffic to an entry relay, plus its size and timing; the entry relay knows the sender; the middle relay knows neither end; the exit relay knows the destination and reads plain HTTP; the website sees the exit’s address. The router does not protect traffic on its own Wi-Fi, and a compromised router defeats it, so the paper suggests the Tor Browser for end-to-end protection.

The table encodes the paper’s qualitative threat model; the paper does not test any of these observers directly beyond the DNS leak test. Two exposures that matter for a transparent gateway are outside its scope: traffic correlation by an adversary who watches both the entry side and the exit side, and application-level identifiers (cookies, logins, device fingerprints) that pass through Tor unchanged. The paper’s caution covers the second in general terms (browsing and system behaviors that compromise anonymity). A transparent proxy also routes every application, including ones that leak identity, which is why the authors pair it with the Tor Browser where available.

Each bar counts speed tests; the key under the chart tells the two kinds apart. Every download through Tor was slower than every download without it, and most landed between 1 and 1.5 megabits per second. Uploads were slow either way, and some Tor uploads beat some direct ones. The authors found the speed workable: websites loaded and 720p video streamed, but large downloads and full high-definition video were close to impossible.

Speed is measured in megabits per second (Mb/s). One byte is eight bits, so a 1 megabyte (MB) photo is 8 megabits and takes about 8 seconds at 1 Mb/s. The dotted lines mark the averages the paper prints, 1.7 and 8.3. Divide one by the other and Tor runs at about one fifth of the direct speed. The bars put it nearer one sixth; the researcher notes explain why the two disagree.

The histograms are reconstructed from Figures 2 to 5: counts from bar heights and bin edges from the axis ticks. The outer bin edges are the smallest and largest measurements, which gives exact ranges (0.53 to 2.69 Mb/s for Tor downloads). The paper attributes the slowdown to three causes: repeated encryption and decryption, roundabout paths through the relays, and the slowest relay throttling the whole chain. The next demo shows the third.

The table bounds each mean from the bars alone: every value at its bin’s lower edge (with one value pinned at the maximum) gives the lowest possible mean, and the reverse gives the highest. The rank test asks how often a direct test beats a Tor test; for downloads the answer is every pair, so the exact two-sided p is 2 / C(40, 10). These analyses are the page’s, not the paper’s, and treat the bars as exact counts of independent tests.

A request through Tor crosses four links: your home connection and three relays run by volunteers around the world. Drag the sliders. The whole connection moves only as fast as its narrowest pipe, so a fast home connection cannot rescue a slow relay. The table shows what the paper’s measured speeds mean for a real file: pick a size and compare the fastest and slowest tests with and without Tor.

Time equals size divided by speed. A 10 MB file is 80 megabits; at the slowest Tor download in the paper (0.53 Mb/s) it takes about 2.5 minutes, and at the slowest direct download (7.93 Mb/s) about 10 seconds. Try 1 GB to see why the authors found large downloads close to impossible through Tor.

The demo applies only the paper’s rule: end-to-end throughput is bounded by the minimum link capacity. Real Tor throughput also depends on relay load, congestion control, circuit-level flow-control windows, and latency over each hop, and Tor’s path selection weights relays by measured bandwidth, so faster relays carry more circuits. The paper’s observation that “the greater the distance, the greater impact on the speed” is reported without data, so the page does not model distance.

• A Raspberry Pi and free Tor software, about $100 in all, can give every device on a Wi-Fi network the privacy protection of Tor.
• The box met five of the authors’ six goals: low cost, privacy from the moment a device connects, simplicity, ease of setup, and everyday usefulness.
• The sixth goal, speed, was traded away: downloads topped out near 2 megabits per second.
• Websites loaded and 720p video played; big downloads and full high-definition video did not work well.
• A test of website lookups found no leaks around Tor.

• Through the router, the 30 download tests ran between about 0.5 and 2.7 Mb/s, most often between 1 and 1.4 Mb/s; without Tor, downloads ran between 7.9 and 9.6 Mb/s.
• The paper prints average download speeds of 1.7 with Tor and 8.3 without.
• Uploads through Tor ran from almost nothing to 0.62 Mb/s; without Tor, from 0.31 to 0.83 Mb/s.
• The DNS leak test showed the router answered lookups through Tor instead of a regular DNS server.
• Anyone else on the router’s own Wi-Fi can still see traffic before it enters Tor, and the exit relay reads anything not protected by HTTPS.

• Feasibility. A Raspberry Pi 3 with Raspbian Stretch Lite, a second Wi-Fi interface, DHCP, NAT, and Tor at boot forms a portable transparent Tor gateway for about $100.
• Goals. Five of six met (cost, immediacy, simplicity, ease of execution, functionality); speed was sacrificed.
• Throughput. Tor downloads 0.53 to 2.69 Mb/s (30 tests, modal bin 0.96 to 1.38); direct downloads 7.93 to 9.60 Mb/s (10 plotted tests). Printed averages: 1.7 and 8.3. Tor uploads 0.01 to 0.62 Mb/s; direct uploads 0.31 to 0.83 Mb/s.
• Usability. 720p streaming and general browsing worked; large files and full HD did not.
• DNS. No leak; lookups resolved through Tor.
• Limitations stated. Local Wi-Fi traffic is exposed before Tor, the router itself is a single point of compromise, the exit relay reads unencrypted traffic, and user behavior (plug-ins, torrents, no HTTPS) can defeat anonymity.

Many devices people own cannot run privacy software at all: game consoles, smart televisions, voice assistants, and older phones. A router that applies Tor to everything behind it protects them without installing anything, and it fits in a pocket for use on hotel or café Wi-Fi. The paper is also honest about the cost, measuring how much speed privacy takes and naming what the box does not hide. Ultimately, it shows that three undergraduates and their advisor can build working network privacy from about $100 of parts.

The design moves privacy from the endpoint to the network path, which covers devices that cannot run Tor themselves and removes the setup burden from users. The cost is a single trusted box and a shared local network that sits outside the protection. The measurements give a concrete bound on what users trade: an order-of-magnitude drop in download speed on the test network, with interactive use intact.

Transparent Tor gateways trade application-level protections (Tor Browser’s fingerprinting defenses and stream isolation) for coverage of every device, and the paper’s contribution is a low-cost, reproducible build with a first measurement of its usability. The evaluation is small and descriptive, which suits a consumer-electronics feasibility study; the throughput data would support stronger claims with paired, interleaved runs, a named test server, and timestamps. Its stated limitations (the local network, the router as a target, and the exit relay) remain the right checklist for anyone building one.

Notes from building this page

• Printed averages do not fit the bars. With every bar’s values placed as low or as high as its bin allows, the Tor download mean must lie between 1.22 and 1.62 Mb/s and the direct download mean between 8.43 and 8.76 Mb/s. The text prints 1.7 and 8.3, both outside. The averages may come from a different set of runs than the plotted ones (see the next note), or from a different speed-test summary.
• Sample sizes. All four figure titles read n = 30. Figures 2 and 4 hold 30 tests each; Figures 3 and 5 (without Tor) hold 10 each. If 30 direct tests were run, 20 are missing from the plots.
• Units. The text gives the averages in “MB/s” (megabytes); the figure captions, axes, and the 2 Mb/s cap use Mb/s (megabits). Read as megabytes, the averages would be 13.6 and 66.4 Mb/s, far above every plotted bar, so the page reads them as Mb/s.
• Bin choice. The four histograms use different numbers of bins (five, four, five, and six) spanning each sample’s own minimum to maximum, so bar widths differ between panels. The page draws all four on a shared axis.
• Test conditions. The paper does not name the speed-test service or server, the times of the runs, whether Tor and direct runs were interleaved, or the upstream link. “The greater the distance, the greater impact on the speed” suggests multiple servers, which would make the samples heterogeneous. Under these unknowns the page’s rank tests show only that the plotted distributions are separated (downloads: U = 300 of 300, exact two-sided p = 2.4 × 10⁻⁹) or mostly separated (uploads: U between 231 and 290 of 300, p between 3.3 × 10⁻⁷ and 0.010).
• The DNS leak test. The paper reports the outcome but not the tool or the router’s DNS configuration under Tor; Section III-A configures Google Public DNS before Tor is added. A short note on how DNS was redirected into Tor (for example, Tor’s DNS port) would let readers reproduce the result.
• The onion in the first demo follows Section II-B’s description (each layer names the next hop). Tor itself builds a circuit once and then sends fixed-size cells without per-cell routing headers; the page says so under the demo.

Try this in class

1. Build a paper onion. Write a message on a card, put it in an envelope addressed “to the website,” put that envelope in one addressed to student C, that one in one addressed to student B, and hand it to student A. Each student opens one envelope and passes the rest on. Afterward, ask each student what they knew about the sender and the final destination.
2. Use the speed demo to estimate how long a 25 MB file takes at the fastest and slowest Tor download speeds, then check your answers with the table in the last demo by trying nearby sizes.
3. Use the second demo to list everyone who can still see something with the Tor router on and HTTPS off. For each one, propose a change that would hide it, and check whether the paper suggests the same fix.