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.

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

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.

§4 / Table 1 evaluation

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 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

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

Wiley's Bayesian classifier against obfuscated protocols (Dust, SSL, obfs-openssh) found that entropy detection achieved 94% accuracy using only the first packet, timing-based detection achieved 89% accuracy over entire packet streams, and length-based detection achieved only 16% accuracy.

2016-khattak-sok §2.4.1 random-payload-detecttraffic-shapeml-classifier

All trained ML classifiers (K-NN, Naive Bayes, ANN, SVM, vote ensemble) performed at near-chance levels when distinguishing RSA-encrypted stego messages from clean photos — best precision 52.05%, best meaningful recall 61.52% (K-NN on clean class). The authors attribute this to embedding only a few hundred bytes into cover photos hundreds of KB in size, with natural image entropy in noisy pixel regions being empirically indistinguishable from RSA-ciphertext statistics.

2013-invernizzi-message §5.1, Table 1 ml-classifierrandom-payload-detect

Stage 1 of the detection pipeline uses a lightweight heuristic: restrict analysis to IP addresses in "VPS-dense ASNs," which censors already target for resource-intensive inspection of fully-encrypted traffic. This pre-filter dramatically reduces the search space before applying the more expensive dual-role behavioral analysis. The evaluation was conducted without Stages 1 and 3 due to dataset limitations, meaning the reported 23% recall and 0.18% FPR are conservative lower bounds on the full pipeline's performance.

2026-almutairi-server §2.1, §2.2, §3.4 fully-encrypted-detectdpiml-classifier

The host-profiling censor (passive traffic analysis: count connections per server, block those exceeding a threshold τ within a window w) blocks essentially all circumvention user traffic within 30 time steps for all classifier qualities tested (ρ_TP ∈ {0.9, 0.95, 0.99}), while causing far less collateral damage than zig-zag (never exceeding ~30% innocent server blocking). Snowflake resists this attack well: with w=3, τ=3, over 94.48% of users receive a proxy within 2 steps even with worst-classifier rules, and final unblocked server rates are 91.24–99.04%. The host profiling approach is feasible for passive censors who cannot enumerate the distribution channel.

2026-fares-game §5.2, Table 2, Table 3 traffic-shapeml-classifier