Sever & DeepLoop
Sever
I’ve been tracing side‑channel vectors in a post‑quantum key exchange, and I think there’s a subtle timing loop we might exploit before anyone else spots it. what do you think?
DeepLoop
Sounds like a classic “loop in the loop” situation. Where’s the timing edge, and how do you plan to isolate it from the noise? Let's sketch the causal chain first; the devil usually hides in the assumptions.
Sever
1. The protocol does a modular exponentiation; the loop counter is visible in the processor pipeline.
2. Each iteration takes a slightly different amount of time because of branch prediction and cache state.
3. An external observer can send a burst of packets and measure the round‑trip latency with a nanosecond resolution clock.
4. By sending many packets with slightly different key‑shares, the attacker gets a set of timing samples that correlate with the loop counter value.
5. Use a low‑pass filter on the timing data to reduce random jitter, then run a simple linear regression to map timing offsets to specific loop counts.
6. Once the mapping is established, the attacker can recover the secret key bits by observing the loop count in real time.
The key edge is the small delay introduced by the branch predictor; the noise is isolated by keeping the system’s clock and temperature constant and by using a high‑frequency timestamp counter.
DeepLoop
Looks like a textbook timing side‑channel, but those “small” branch‑predictor delays usually bleed into the rest of the pipeline. A few things to double‑check: 1) does the processor flush the pipeline on each packet, or does it share state across bursts? 2) how linear is the relationship between loop count and latency when the cache lines are in different states? 3) a low‑pass filter will kill the very jitter you need to tease out the predictor effect. Maybe try a differential measurement – send two packets back‑to‑back with identical payloads but different secret parts – that should cancel out a lot of the constant‑time noise. Also, linear regression on a non‑linear process might give you a misleading slope. In short, the plan is solid, but the devil will be in those edge‑case timing fluctuations that your filter might be masking. Good luck, and keep the debugging logs coming.
Sever
1. The processor does not flush the pipeline on each packet – state persists across bursts, so that’s a factor.
2. The loop‑latency curve is piecewise linear, but the slope changes sharply when a cache line moves from L1 to L2.
3. A differential measurement is the way to go; by subtracting the two back‑to‑back timestamps you cancel out most of the constant‑time overhead.
I’ll run a quick script that injects two packets with only the secret byte differing and log the raw timestamps. From there I can isolate the predictor jitter and fit a piecewise model instead of a single line. Keep the logs; every microsecond of variance matters.
DeepLoop
Nice. Just be careful the differential doesn’t wipe out the subtle predictor signal—sometimes the subtraction itself introduces a new jitter. Keep an eye on the slope jumps when the cache moves; those are your true footholds. And don’t forget to sanity‑check the model against a few fresh samples; the curve can shift if the clock hiccups. Good luck, and log those microseconds.
Sever
Got it. I’ll capture raw timestamps, then compute the differential carefully so we don’t add extra jitter. I’ll monitor slope changes at cache boundaries and run fresh checks against a new batch of packets to keep the model stable. Logging everything now.
DeepLoop
Sounds like a good loop‑analysis routine. Keep the logs tidy, and remember: the first few mis‑fits are usually the ones that teach you where the real edge lies. Good luck, and may your differential never be a source of new surprises.