A pre-shared key enables encrypting the entire GoHop packet—header, payload, and padding bytes—achieving true randomness in the full byte stream. Standard VPN protocols such as OpenVPN encrypt only the payload while leaving headers in plaintext, exposing protocol-identifying fields to DPI without payload inspection. This design choice is a prerequisite for defeating header-based fingerprinting.

GoHop without traffic shaping achieved 76.8–78.5 Mbps (virtual NIC) on a 1 Gbps LAN; traffic shaping reduced this to 58.1 Mbps (~26% overhead from fragmentation). In a Beijing-to-Seattle real-world download test, GoHop delivered 960–999 KB/s against a 1,544 KB/s direct baseline, with the 96.7 Mbps WAN link—not GoHop—as the bottleneck. This compares to Tor's 40–300 KB/s (30–80 KB/s with obfuscation plugins such as SkypeMorph).

§V.B, Table II, Table III evaluation

Packet padding alone is insufficient to defeat statistical traffic analysis unless every packet is padded to MTU; small-size padding has minimal effect on classifier accuracy (citing Hjelmvik & John 2010). Traffic shaping that also fragments large packets—transforming the full packet-size CDF to match a target distribution rather than merely inflating small packets—is required to statistically impersonate a target traffic class.

§III.B defense

Spreading UDP datagrams across a randomized port range breaks traditional 5-tuple-based session tracking, randomizes per-port inter-arrival times, and reduces per-port throughput to a small fraction of the aggregate—making per-flow statistical analysis significantly harder. Critically, the number of random ports does not reduce aggregate throughput: GoHop measured 76.8 Mbps (1 port) versus 78.5 Mbps (100 ports) at the virtual NIC.

§III.C, §V.A, Table II defense

GoHop's naïve traffic shaping targeting a uniform packet-size distribution (0–MTU) successfully morphed both HTTP and SSH flows: K-S test D values were 0.019 (HTTP) and 0.022 (SSH), both below the 0.025 rejection threshold, with p-values of 0.20 and 0.11 respectively. After shaping, packet-size CDFs and statistical metrics (mean ~782–783 bytes, variance ~163,600) for both protocols became nearly identical, eliminating the size signals that distinguish them.

§V.A, Table I evaluation

State-of-the-art ML-based obfs4 detection (Wang et al. decision tree) achieves 97% precision at equal base rates (λ=1) but precision collapses to 3% at a still-conservative λ=1,000; at λ=10⁶ precision approaches zero for all classifiers tested. This base-rate failure was previously uncharacterized because prior evaluations only considered balanced or near-balanced datasets.

2024-wails-precisely §IV-D (Scalability), Figure 3, Table I ml-classifierrandom-payload-detectdpi

The GFW detects Shadowsocks by flagging apparently high-entropy connections that are not TLS or HTTP, but this detection is brittle: connections are explicitly allowed if the first 6 bytes of the first packet of a flow are all printable ASCII characters (range 0x20–0x7E). Adding a 6-byte alphanumeric preamble to the Shadowsocks message definition is sufficient to bypass this heuristic and requires only a short patch to the protocol specification file.

2023-wails-proteus §3.2 random-payload-detectfully-encrypted-detectdpi

The GFW's fully-encrypted detector (deployed Nov 2021) operates by exempting likely-benign traffic and blocking the rest. Five inferred exemption rules applied to the first TCP payload (pkt): Ex1 — popcount(pkt)/len(pkt) ≤ 3.4 or ≥ 4.6 (bits/byte); Ex2 — first 6+ bytes are printable ASCII [0x20–0x7e]; Ex3 — more than 50% of bytes are printable ASCII; Ex4 — more than 20 contiguous printable ASCII bytes; Ex5 — first bytes match TLS or HTTP fingerprint. Traffic failing all five exemptions is blocked. Experiments confirmed all rules still held as of February 2023.

2023-wu-fully-encrypted-detect §4, Algorithm 1 fully-encrypted-detectdpirandom-payload-detect

Current randomized-payload circumvention tools (obfs4/ScrambleSuit, SkypeMorph, VoIP-tunneling) rely on censors 'defaulting open' — treating unidentified traffic as innocuous. If censors instead block all traffic not explicitly recognizable as meaningful plaintext, these tools fail entirely. The paper notes anecdotal evidence this is already occurring, including blocking of some TLS 1.3 connections.

2021-kaptchuk-meteor §1 Introduction random-payload-detectfully-encrypted-detectdpi

The GFW's passive classifier uses two features of the first data packet to flag probable Shadowsocks traffic: (1) high Shannon entropy (per-byte entropy > ~7 bits strongly correlates with replay probability, which is nearly 4x higher at entropy 7.2 than at 3.0) and (2) packet length in the range 160–700 bytes with specific remainders mod 16. A single data packet after the TCP handshake is sufficient to trigger the downstream active-probing pipeline.

2020-alice-shadowsocks-detection §4.2 dpirandom-payload-detecttraffic-shape

Measured packet loss rates under GFW censorship (Feb–Apr 2017, client at Tsinghua University/CERNET): Tor with meek obfuscation suffers 4.4% average PLR; Shadowsocks (AES-256-CFB) suffers 0.77% PLR; native VPN (PPTP/L2TP) and OpenVPN both achieve ~0.21% PLR. For comparison, the same tools accessed from a US vantage point show PLR below 0.1%, confirming the excess loss is GFW-induced. The GFW's DPI and active probing techniques specifically target Tor and Shadowsocks protocol signatures.

2017-lu-accessing §4.3 dpiactive-probingrandom-payload-detect