Chapter 4 — Quantum and post-quantum security: competing explanations | Master's Quantum and post-quantum security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 04 published. Map, example, EX020.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["4.1 Rivals for the failure rise"]
  N2["4.2 Predictions"]
  N3["4.3 Practical activity — Lab 4: stratify by path"]
  N4["4.4 Aggregation reversals"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX020"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["4.1 Rivals for the failure rise"]
  N2["4.2 Predictions"]
  N3["4.3 Practical activity — Lab 4: stratify by path"]
  N4["4.4 Aggregation reversals"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX020"]

[Learning outcomes and connection]
    |
    v
[4.1 Rivals for the failure rise]
    |
    v
[4.2 Predictions]
    |
    v
[4.3 Practical activity — Lab 4: stratify by path]
    |
    v
[4.4 Aggregation reversals]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX020]

Learning outcomes and connection

You will (1) list rival explanations for an observed effect; (2) predict what each rival implies in data you can collect; (3) use stratification to discriminate between rivals; and (4) recognize when a pattern reverses on aggregation. It applies the design of Chapter 3 and shapes the proposal of Chapter 5.

4.1 Rivals for the failure rise

Size mechanism — multi-packet ClientHello mishandled by the legacy proxy or by some servers.
Software update — the managed-browser update shipped the same week changed other behaviour.
Unknown codepoint — some middlebox rejects an unrecognized supported-group value (0x11EC for X25519MLKEM768 in the IANA registry), regardless of size.
Seasonality — term started; more users, more unusual destinations.
Reporting artefact — a help-desk campaign encouraged reporting, raising tickets but not failures.

Write each rival down with the data that would weaken it before looking at results.

4.2 Predictions

Each rival predicts a different fingerprint. Size predicts failures concentrated on the path containing the inspecting proxy and among destinations reached through it, appearing only when the hello crosses a segment boundary — the testbed can vary padding to cross or not cross it. The update predicts a rise on both paths. Unknown codepoint predicts failure even when the hybrid share is small enough to fit one segment (testable by offering the codepoint with padding removed, in the testbed only). Seasonality predicts a rise in the control group too. Reporting artefact predicts tickets rising without logged failures rising. Writing these predictions before analysis prevents post-hoc storytelling.

4.3 Practical activity — Lab 4: stratify by path

# Lab 4 (synthetic): competing explanations. Is the failure rise caused by ClientHello size,
# or by the client software update shipped the same week? Stratify by path type.
data = {  # (path, hybrid offered): (failures, attempts)
    ("direct", False): (8, 20000), ("direct", True): (9, 20000),
    ("legacy proxy", False): (10, 20000), ("legacy proxy", True): (52, 20000)}
for path in ("direct", "legacy proxy"):
    r0 = 1e4 * data[(path, False)][0] / data[(path, False)][1]
    r1 = 1e4 * data[(path, True)][0] / data[(path, True)][1]
    print(f"{path:13s} before {r0:4.1f}/10k  after {r1:4.1f}/10k  difference {r1-r0:+5.1f}")

Expected output:

direct        before  4.0/10k  after  4.5/10k  difference  +0.5
legacy proxy  before  5.0/10k  after 26.0/10k  difference +21.0

The aggregate rise is almost entirely on the legacy-proxy path; the direct path barely moves. A browser update would have affected both paths, so rival 2 is weakened. The pattern fits the size mechanism and the unknown-codepoint mechanism equally — only the testbed can separate those two. This is the central lesson of the chapter: one stratification eliminates some rivals, not all.

The lab's before and after totals match Lab 3: 18 and 61 failures out of 40,000 series. Splitting by path shows where the change happened. The direct path's half-point rise is within noise for these counts, while the proxy path's rise is large. Neither stratum yet distinguishes size from codepoint; that needs the testbed with padding varied.

4.4 Aggregation reversals

Stratified and aggregate comparisons can disagree. If the hybrid group were enabled first for users who mostly use the direct path, the aggregate failure rate could fall after enabling it even though, within the proxy path, it rose. This is Simpson's paradox; the defence is to report path-stratified rates alongside the aggregate and to explain any reversal rather than choosing the convenient level.

In the Fragment Study the staggered rollout randomized by device identifier makes this reversal unlikely, because both cohorts should use the two paths in similar proportions. Check that assumption with a balance table of path use by cohort before reporting either level. If the cohorts turn out to be unbalanced, report both levels and explain the difference.

4.5 Worked example: interview evidence

Help-desk interviews (I01–I06, synthetic) report that complaints came "mostly from the hospital wing" and that clearing the cache "sometimes fixed it". The first is consistent with the proxy path. The second points to a further rival: some clients retried with a smaller hello after a failure (browsers can fall back), so failures were intermittent. Qualitative evidence suggested a mechanism the logs could then test — the series-level unit of analysis from Chapter 3 shows whether retries succeeded without the hybrid share.

4.6 Common errors and limits

Testing only the favoured explanation.
Treating consistency with one rival as proof when another predicts the same pattern.
Reporting only the aggregate (or only the stratum) that tells the preferred story.
Running codepoint or size experiments against production middleboxes; use the testbed.

Each error has a guard used in this chapter: five rivals listed before analysis, predictions that tell them apart, both aggregate and path-level rates reported, and all size and codepoint experiments run on an isolated copy of the proxy. Interview evidence is used to suggest tests, not to settle them.

Exercises — chapter 4

EX020 — Rival table. Build a table of the five rivals with their predicted fingerprints. Rubric: 3 = each prediction observable.
EX021 — Add a rival. Propose a sixth rival and its prediction. Rubric: 3 = plausible and discriminable.
EX022 — Extend Lab 4. Add a "Wi-Fi guest" path with 6 and 7 failures per 20,000 before/after. Interpret. Rubric: 3 = correct difference and interpretation.
EX023 — Simpson construction. Construct numbers where the aggregate rate falls while both strata rise. Rubric: 3 = arithmetic correct and mechanism explained.
EX024 — Separate size from codepoint. Design a testbed experiment that separates rivals 1 and 3. Rubric: 3 = varies size and codepoint independently, isolated environment.
EX025 — Qualitative to quantitative. Turn interview statement "clearing the cache fixed it" into a testable log query. Rubric: 3 = query uses series-level outcome.

Chapter synthesis

An effect has rivals; each rival predicts a fingerprint; stratification and testbed variation eliminate rivals one by one; and aggregate and stratified results must both be reported.

Continue studying — chapter 04 of 08

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →