Secret-Independent Resource Scheduling¶

Method — instantiates Side-Channel Leakage Containment

Executes work so that time, memory access, and resource contention do not depend on the secret — closing the timing and resource-use channels by making every secret take the same observable path.

When how long an operation takes — or which branches, cache lines, or shared resources it touches — varies with a secret, an observer measuring those resources learns the secret without ever seeing the answer. Secret-Independent Resource Scheduling removes that dependency at the source: it makes execution follow the same observable path — same timing, same access pattern, same resource footprint — regardless of the protected value, and it isolates shared resources so that contention can't carry the signal between tenants. Its defining move is to equalize the timing and resource-use observable at the point of computation, before any response leaves — where its output-shaping siblings equalize the response after the fact.

Example¶

A login service handles sign-in attempts. A naive implementation returns "no such user" quickly, because it can bail out the moment it fails to find the account, but takes longer on a real account because it goes on to hash and compare the password. An observer timing the responses can therefore tell which usernames exist — a leak that never touches the response body. The control removes the dependency: the service performs the same work whether or not the account exists, running a full credential comparison against a dummy hash for missing accounts so the response time no longer distinguishes the two cases.

The same discipline governs the token check underneath. Instead of a comparison that returns on the first mismatched byte — leaking, through timing, how much of a secret was guessed correctly — it uses a constant-time comparison that always examines every byte. And it runs on a scheduling slot isolated from other tenants, so their work can't be timed through shared contention. Constant-time comparison is the standard defense against timing side channels in credential and message-authentication checks.

How it works¶

Find the secret-dependent path. Locate branches, early exits, and memory accesses whose behavior varies with the protected value — the timing and cache channels the inventory flagged.
Make it data-oblivious. Replace them with equivalents that do the same work on every input: constant-time comparisons, fixed access patterns, no early return.
Isolate the shared resource. Give the work a dedicated scheduling slot or partition so contention on a shared resource can't leak across tenants.
Pay the worst case, always. Every operation takes the time the slowest case would, because varying the time is exactly the leak.

Tuning parameters¶

Resources equalized — time, cache, memory-access pattern, power. Each closed channel adds cost; close the ones the inventory shows leak.
Isolation strength — soft (scheduling discipline) vs. hard (dedicated partition). Harder isolation resists cross-tenant timing but wastes capacity.
Performance budget — constant-time means everyone pays the worst-case latency; the dial is how much throughput you'll trade for the closed channel.
Granularity — apply per-operation (just the sensitive compare) or across a whole service. Narrower is cheaper but risks leaving an adjacent path secret-dependent.
Verification depth — how rigorously the invariance is measured rather than assumed, since the property is easy to lose silently.

When it helps, and when it misleads¶

Its strength is closing timing and contention channels at the root, before any output is produced, and doing so robustly against repeated measurement — an observer who times ten thousand requests learns no more than one who times one. For credential, key, and authentication operations it is often the only control that closes the channel at all.

Its traps are subtle and famous. Constant-time code is easy to get almost right and have a compiler optimization quietly reintroduce a secret-dependent branch, so the property silently regresses. It forces the worst-case cost on every request, which is real. And deep microarchitectural channels — speculative execution, shared prediction state — can survive source-level constant-time entirely, so "looks constant-time" is not "is constant-time." Constant-time programming is the discipline of removing secret-dependent timing, and its cardinal rule is that the property must be measured, not assumed, because the toolchain can undo it beneath you.^[1] The discipline that guards against this is to verify the timing distribution empirically — the job of the regression suite — rather than trusting the source to still be constant-time after the next build.

How it implements the components¶

This method fills the resource-isolation and timing-equalization components — the computation-side controls:

shared_resource_isolation_boundary — partitions or dedicates the shared resource so contention can't carry a signal between tenants or operations.
output_equalization_policy — equalizes the timing and resource-use observable so it is the same across every secret value.

It equalizes the timing/resource channel only. Response *size padding belongs to Response Padding or Coarsening; the cache-specific partition-or-flush discipline belongs to Cache Partitioning or Flush Rule; and injecting timing noise rather than removing the dependency belongs to Controlled Noise Injection.*

Instantiates: Side-Channel Leakage Containment — makes execution secret-independent so timing and resource use reveal nothing.
Consumes: Side-Channel Inventory Workshop identifies which resource channels vary with the secret.
Sibling mechanisms: Response Padding or Coarsening · Side-Channel Regression Test · Cache Partitioning or Flush Rule · Constant Response Envelope · Side-Channel Inventory Workshop · Query Rate and Composition Limit · Residual Leakage Review Board · Threshold Suppression · Privacy-Preserving Telemetry View · Batching and Delayed Release · Broker Visibility Partitioning · Controlled Noise Injection · Differential Observation Test · Error Message Normalization · Metadata Minimization Filter

Notes¶

This method pairs tightly with Side-Channel Regression Test: constant-time and fixed-access properties regress silently under compiler and library upgrades, so a fix here is only as durable as the test that re-measures the timing distribution on every change. It closes the timing channel; Cache Partitioning or Flush Rule addresses the cache-state channel specifically, and the two are often deployed together on the same sensitive path.

References¶

[1] Constant-time programming is the discipline of writing code whose execution time — and, more broadly, whose observable resource use — does not depend on secret values, so an observer timing the operation learns nothing about the secret. Its defining caution is that the property is fragile: a compiler optimization or a refactor can silently reintroduce a secret-dependent path, so it must be verified by measurement rather than assumed from the source. ↩