G-Lox Uses Two-Party Computation to Hide Bridge Assignments from Censors

G-Lox cuts client overhead to 0.25 seconds per iteration while preventing any single server from seeing which group gets which bridge.

Two Servers, One Blind Assignment

Bridge distribution for censorship circumvention has a fundamental tension: you need to adapt assignments based on blocking reports, but you can't let the distributor learn which bridges go to which users. Lox solved half the problem with distributor blindness. G-Lox extends that to stateful group-level adaptation without leaking group identifiers.

The trick is a two-server privacy wall. All adaptive logic -- blockage reporting, transport-aware reassignment, group splitting -- runs behind secure two-party computation using DPF/FSS protocols. No single server ever sees the full picture.

Measured Overhead, Not Theoretical Promises

The C++/EMP implementation over real TCP sockets delivers concrete numbers. At M=1024 groups, the client sends 1,968 bytes, receives 1,280 bytes, and completes an iteration in about 0.25 seconds. State sizes up to $2^{16}$ keep communication in the low-KiB range per round.

Simulations pit G-Lox against Lox and rBridge baselines under group-specific blocking and Sybil enumeration. The results show improved robustness among systems that maintain broad issuance.

Why This Matters for Real Censorship Landscapes

Censors increasingly target bridge distribution infrastructure. G-Lox makes it harder for them to isolate and block specific user groups by observation alone. The privacy wall means sweeping a distributor server gives an adversary nothing useful.

The next step is scaling beyond the prototype: production deployment needs to handle millions of groups while keeping latency under a second. The current numbers suggest that's feasible.

Source: G-Lox: Group-Adaptive, Privacy-Preserving Bridge Distribution with Two-Party Computation
Domain: arxiv.org