Variable-length sampling (Adaptation 2) achieves a provably secure but impractical encoding: a 16-byte plaintext encoded with GPT-2 requires 502–2994 tokens, produces 2.3–13.6 KiB of stegotext (149×–870× overhead), and takes 42–765 seconds even with GPU acceleration, depending on security parameter k=16–128.

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.

§1 Introduction detection

Classical public-key steganography (Algorithm 1 from [54]) has a 100% failure rate when encoding a 16-byte message using GPT-2, because GPT-2's per-token entropy drops near zero frequently and standard rejection sampling cannot find an acceptable token. Entropy bounding reduces failure to 0–10% but introduces detectable statistical bias: selected tokens come from a visibly different probability distribution than baseline samples.

§4 Adapting Classical Steganographic Schemes / Figure 2b evaluation

Meteor encodes bits by embedding a PRG-masked random value into the token-sampling randomness of a generative model, recovering bits proportional to the shared prefix length of the sampled interval. Expected throughput per sampling event is asymptotically within 1/2 of the Shannon entropy of the channel (proven in Appendix A), so Meteor automatically adapts to high entropy variability without explicit signaling or padding.

§5 Meteor / §5.2 defense

Meteor is proven secure against chosen-hiddentext attacks: any PPT adversary distinguishing Meteor output from honest model output can be reduced to breaking the underlying PRG. The scheme produces stegotext provably indistinguishable from the generative model's own output distribution, and requires only a shared public model — not a secret channel — making the model analogous to a common random string. On GPU the encoding overhead is ~1× model-load time; on CPU ~4.6×; on mobile ~49.5×.

§5.2 / §6 / Table 2 defense

Drivel evaluates its design against the GFW's fully-encrypted-traffic detector (documented in Wu et al. 2023). The thesis demonstrates that switching to post-quantum primitives does not by itself change the traffic's appearance to a statistical censor classifier — the fully-encrypted detection problem is independent of the underlying cryptographic algorithm and must be addressed at the traffic-shaping layer regardless of key-exchange choice.

2025-himmelberger-drivel §3, §4 fully-encrypted-detectrandom-payload-detect

Drivel is an obfs4-style fully-encrypted proxy protocol that replaces obfs4's pre-quantum cryptographic primitives with post-quantum alternatives. It is one of the first circumvention protocols explicitly designed to remain secure under a quantum adversary, addressing the forward-secrecy threat to deployed circumvention traffic recorded today for future decryption.

2025-himmelberger-drivel §1, §2 fully-encrypted-detectrandom-payload-detect

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

obfs4 and obfs⋆ produce characteristic wire patterns—bursts of roughly MTU-sized payloads followed by a randomly-sized chaff packet—that CNN classifiers detect purely from packet-size sequences without payload inspection. A trivial per-bridge entropy-biasing re-encoding (obfs⋆) completely defeats the hand-tuned decision tree (0% precision, 0% recall) but does not reduce CNN detectability, because the CNN generalizes across size-distribution variants.

2024-wails-precisely §V-E, §IV-D-3, Figure 4 traffic-shapeml-classifierrandom-payload-detect

Despite fully encrypted protocols existing since obfs2 in 2012, the first documented evidence of the GFW passively detecting them purely by randomness appeared only in 2021 — approximately a decade later — and was limited to certain foreign IP address ranges and a subsampled fraction of traffic. Meanwhile, the GFW had been discovering obfs2/obfs3 servers via active probing as early as 2013, indicating censors found active-probing-based address discovery cheaper and more reliable than passive statistical classifiers for this protocol family.

2023-fifield-comments §5 fully-encrypted-detectactive-probingrandom-payload-detect

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