Constant Response Envelope¶
Output-equalization policy — instantiates Side-Channel Leakage Containment
Forces every response into one fixed envelope — same size class, structure, status, and timing band — so the form of the answer never varies with the protected fact.
A response can be within policy in its content yet leak through its form — a slower reply, a longer body, a different status code for the "real" case. Constant Response Envelope fixes a single envelope that every response must conform to — same size class, same structure, same status, same timing band — whether the protected fact is present or absent, true or false. Its defining move is to make the observable shape of a reply a constant, decided in advance and independent of the branch taken inside, so an observer comparing two responses finds them indistinguishable up to a declared budget. Where Batching and Delayed Release equalizes timing across many releases, this equalizes the form of each single response; where Error Message Normalization handles the failure branch, this fixes the whole envelope, success included.
Example¶
A "forgot password" endpoint must not reveal which email addresses have accounts — an authorized action (sending a reset link) can leak an unauthorized fact (account existence) through its response. Left naive, the endpoint returns "no account found" for unknown emails and "reset link sent" for known ones, and the difference in message, size, or latency lets anyone test membership. Under a constant envelope, every request returns the identical body — "If an account exists, a reset link has been sent" — the same 200 status, the same response size, and a timing padded to the same band regardless of whether a lookup and send actually happened. The response form no longer distinguishes a real account from a fabricated one. This is the standard defense against account enumeration.[1]
How it works¶
- Define one canonical envelope. Fix the permitted size class, structure, status, and timing band a response may exhibit.
- Map every branch onto it. Whatever happens internally — hit or miss, allow or deny — the outward response is coerced into the same envelope.
- Equalize each observable dimension. Pad body length to a size class, normalize status, and hold timing to a fixed band so no dimension tracks the secret.
- Set the tolerance explicitly. Choose how equal "equal" must be — the residual distinguishability the envelope is allowed to leave.
Tuning parameters¶
- Dimensions covered — size, status, timing, headers; each dimension closed removes a channel but adds rigidity.
- Timing-band width — pad to a fixed maximum vs. a band; tighter bands leak less but raise the latency floor for everyone.
- Sameness granularity — byte-identical responses vs. same-size-class; identical is safest, class-based is cheaper and more flexible.
- Distinguishability budget — how much residual variation is tolerated before the envelope is considered leaky; the acceptance target the design is held to.
When it helps, and when it misleads¶
Its strength is closing existence-, membership-, and branch-distinguishing leaks at the point they escape — the response itself. Its cost is a latency floor and less-informative replies for legitimate users, who lose the specific feedback the envelope suppresses. The classic misuse is equalizing the body while leaving timing untouched — a fast reject and a slow accept still separate the cases, so an envelope that omits the timing dimension leaks anyway. The discipline is to include every observable dimension and to confirm indistinguishability empirically with a Differential Observation Test rather than assuming the envelope is tight.[1]
How it implements the components¶
output_equalization_policy— the canonical fixed envelope is this policy: the rule that every response present the same observable form.distinguishability_or_leakage_budget— the envelope's tolerance sets how much residual distinguishability between responses is acceptable.
It fixes the form of each response; spreading releases over time is Batching and Delayed Release's release_delay_or_batching_window, blurring values with noise is Controlled Noise Injection's, and coarsening body size specifically is Response Padding or Coarsening's.
Related¶
- Instantiates: Side-Channel Leakage Containment — the envelope removes response-form channels from the observation surface.
- Sibling mechanisms: Error Message Normalization · Differential Observation Test · Batching and Delayed Release · Response Padding or Coarsening · Controlled Noise Injection
References¶
[1] Account (user) enumeration — leaking whether an account exists via differing responses to login, registration, or password-reset requests. The established defense is a response identical in content, status, size, and timing regardless of account existence. ↩