Response Padding or Coarsening¶

Method — instantiates Side-Channel Leakage Containment

Pads response size and coarsens response precision to fixed buckets, so that size and granularity — not just content — reveal nothing that distinguishes one protected state from another.

A response can be authorized in content and still leak in shape. A longer ciphertext betrays a longer plaintext; a more precise coordinate narrows a location; a bigger result page reveals how many records matched. Response Padding or Coarsening equalizes those observable dimensions: it pads every response up to a fixed size class and rounds every value to a fixed granularity, so that within a bucket, distinct secrets look identical. Its defining move is that it operates on the shape of the output — bytes on the wire, decimal places, grid cells — not on its timing (that's scheduling) and not on whether it exists at all (that's suppression). The bucket width is the guarantee: nothing finer than a bucket can leak.

Example¶

An encrypted document store returns search results whose content is unreadable to the server and to anyone watching the connection. Yet the length of each response still reveals how many documents matched — and match-count can betray protected membership ("this user has access to something in the restricted set"). The control pads each response up to the next fixed size class, so every reply lands on one of a few envelopes — say 4 KB, 16 KB, or 64 KB — and the observable length collapses to a handful of buckets that no longer track the true count.

The same method coarsens precision elsewhere. A location-sharing feature rounds exact coordinates to a fixed grid — a cell on the order of a kilometer — so two people in the same cell are indistinguishable, and the report never resolves finer than the cell. In both cases the width of the bucket is chosen to meet the tolerated leakage budget: pick the coarseness first, and the indistinguishability guarantee follows directly from it.

How it works¶

Choose the shape dimension. Decide which observable to equalize — byte size, numeric precision, or field cardinality — from the channels the inventory flagged.
Define fixed buckets. Fix a ladder of size classes or a rounding grid independent of the data, so the bucket a response lands in doesn't itself encode the secret.
Pad up / round to bucket. Grow each response to its size class or snap each value to its grid cell.
Read the bound off the bucket. The bucket width is the distinguishability guarantee — secrets closer than one bucket are provably indistinguishable on this channel.

Tuning parameters¶

Bucket width / size-class ladder — the core dial. Wider buckets hide more but cost bandwidth (padding) or utility (coarsening); the whole tradeoff lives here.
Dimensions equalized — size only, precision only, or both. Each closed dimension adds overhead, so equalize the channels that actually leak.
Pad-up vs. pad-to-constant — round up to the next class, or force every response to one fixed size. Constant is strongest and most expensive.
Fixed vs. data-dependent buckets — data-dependent boundaries save overhead but can re-leak, because which bucket a value falls in becomes information near the boundary.
Overhead ceiling — the bandwidth or utility cost you'll accept, which caps how strong the equalization can be.

When it helps, and when it misleads¶

Its strength is closing size and precision channels cheaply, without redesigning what the response says — and the guarantee is unusually legible, because the bucket width is the bound in plain sight. It is the natural first control for any channel where the leak rides on how big or how precise the answer is.

Its costs and traps are equally concrete. Coarsening destroys utility — a one-kilometer cell may be useless for the feature it serves — and padding spends real bandwidth. Data-dependent bucket boundaries can quietly re-open the channel, because the boundary between two buckets is itself a bit of information. The classic misuse is to size the buckets to minimize overhead rather than to meet the leakage budget — running the sizing backwards from cost, which produces buckets that look tidy and guarantee nothing. Message length leaking through encryption is a staple of traffic analysis, and length padding is its standard countermeasure.^[1] The discipline that keeps this honest is to derive bucket width from the budget the review board set, then check whether the resulting overhead is affordable — not the other way around.

How it implements the components¶

This method fills the output-shaping components for the size and precision dimensions:

output_equalization_policy — pads and rounds responses to uniform size classes and granularity buckets, so shape carries no distinguishing signal.
distinguishability_or_leakage_budget — realizes the tolerated budget as a concrete bound: the bucket width sets the finest difference that can leak.

It equalizes shape only. Timing and resource-use equalization belong to Secret-Independent Resource Scheduling; withholding a response entirely belongs to Threshold Suppression; and adding randomness rather than removing precision belongs to Controlled Noise Injection.

Instantiates: Side-Channel Leakage Containment — equalizes the size and precision of legitimate outputs so their shape reveals nothing.
Consumes: Residual Leakage Review Board sets the leakage budget that fixes the bucket width.
Sibling mechanisms: Secret-Independent Resource Scheduling · Threshold Suppression · Constant Response Envelope · Side-Channel Inventory Workshop · Query Rate and Composition Limit · Residual Leakage Review Board · Side-Channel Regression Test · Privacy-Preserving Telemetry View · Batching and Delayed Release · Broker Visibility Partitioning · Cache Partitioning or Flush Rule · Controlled Noise Injection · Differential Observation Test · Error Message Normalization · Metadata Minimization Filter

Notes¶

Padding/coarsening and Constant Response Envelope are neighbors that must not be confused: this method equalizes the size and precision of a response's payload, while the envelope mechanism equalizes the response's whole format and structure (and pairs with timing controls). They are often deployed together — a constant envelope with padded contents — but they close different observables.

References¶

[1] Traffic analysis is the study of what can be inferred from the observable metadata of communication — timing, volume, and size — even when the content is encrypted and unreadable. Message length is a classic leak in this class, and padding messages to uniform sizes is the standard countermeasure. ↩