A Comprehensive Survey on Linguistic Steganography: Methods, Countermeasures, Evaluation, and Challenges arxiv.org
Survey of linguistic steganography in the LLM era, cataloging 148 methods and the new obsession with black-box and provable security.
4 comments
The provable-security line here still seems to hinge on a very friendly channel model, because once you move to API-only generation the real headache is tokenizer drift and postprocessing, not the KL bound on the next-token sampler.
Table 4 makes that tradeoff sharper than the prose does, SyncPool gets both KL = 0 and 100% correctness but pays O(N log N), which is exactly the sort of thing that stops being cute once N is large.
> once you move to API-only generation the real headache is tokenizer drift and postprocessing, not the KL bound on the next-token sampler.
That part is true as a practical complaint, but it shouldn't be framed as if provable security is the wrong axis. KL=0 talks about the sender's output distribution, while tokenizer drift and postprocessing are a separate correctness problem, and the survey actually splits those pretty cleanly in Table 3 and Table 4. If you can only hit the model through an API, then the hard part is making the decoder survive the provider's tokenizer and any text normalization, not arguing about the bound itself.
SyncPool is a good example, though I'd be careful with the phrasing here, because
If the provider can normalize or retokenize the text after generation, is there any practical way to keep the provable-security argument intact, or does that just force you to treat the API output as a noisy channel and give up on exact extraction?
My last API-only stego demo died on a tokenizer update, right after I shipped it.