Where the Attack Breaks—and What Defense Costs

PromptEcho’s boundaries and its proposed defenses answer the same question from opposite directions: when does a merged-token length trace become too ambiguous to reconstruct, and how can a service make it more ambiguous on purpose? This chapter focuses on that engineering decision. A low reconstruction rate is not automatically a privacy guarantee, and a defense is not automatically worthwhile if it destroys the low-latency stream users rely on. The useful judgment is conditional: identify the correlation that exposes content, then decide how much bandwidth, latency, and response interactivity the service can spend to weaken it.

A weak reconstruction is not the same as no leakage

The evaluation already shows several places where PromptEcho loses precision. Long responses accumulate ambiguity because each additional segment adds more possible token partitions and more possible semantic continuations. Rare terminology and entity-heavy content are difficult because a language model has weaker priors for low-frequency names, dates, statutes, and specialized expressions. Numerals can be especially fragile: a wrong digit may change the meaning even when the surrounding sentence is plausible. Code and mathematical reasoning are structurally unforgiving because a small token-level mistake can break syntax or alter a formula. Creative writing has the opposite problem: many different phrasings can satisfy similar length constraints.

These are real attack boundaries, but they should not be interpreted as a binary safe zone. A reconstruction that fails to recover a rare name may still identify whether the response concerns a legal dispute or a medical treatment. A response whose code is invalid may still disclose that the user is working on a particular kind of system. A generic template may be recovered while the sensitive payload is lost, which is a failure for one privacy question and a success for another. Risk therefore depends on what an observer needs to learn, not only on whether the output passes an exact-match test.

The paper’s scope is also narrower than the phrase “encrypted LLM traffic” might suggest. The study focuses on single-turn, English-language interactions with remote API services and a passive on-path observer. It does not directly measure multi-turn conversations, other languages, every streaming protocol, local deployments, or future provider designs. Its cross-service observations indicate that the pattern is not necessarily unique to one vendor, but the detailed end-to-end evaluation centers on GPT-4o and DeepSeek-V3 and uses service-specific merged traffic for adaptation. A new model may require a different tokenizer and retraining to align the length symbols with its output style.

The evidence is strongest when the observer can identify the target response, estimate stable service overhead, and apply a compatible model. It weakens when the provider changes buffering, adds metadata, varies aggregation, introduces padding, multiplexes flows, or otherwise breaks the calibrated relationship between content and record size. The paper’s assumption that service-specific offsets remain stable is an empirical condition. It must be rechecked after a protocol or client change, not treated as a permanent property of the API.

Imperfect capture provides a useful but limited stress test. In the authors’ retrained experiments, removing the first merged token to simulate preamble interference lowers ASR by roughly 2–3 percent, because the first token often carries little topic information.