Case Study 38.2: Thirty-Two Test Bits

The situation

A research group has built a working table-top BB84 system and is preparing to publish. Their apparatus produces short blocks — the source is weak and the run times are limited by a cryostat duty cycle — so they get about 800 sifted bits per acquisition.

Key rate is what reviewers will look at, so the parameters were tuned to maximize it. Test bits are pure overhead: announced publicly, then discarded. The group settled on 32 test bits per block, 4%, which felt generous.

Their results table reports, across 200 acquisitions, "QBER consistently below threshold; no evidence of eavesdropping."

A referee asks what QBER their protocol could actually rule out.

Step 1: what 32 bits can see

>>> from vqelab.qkd import test_bits_required, ABORT_THRESHOLD
>>> ABORT_THRESHOLD
0.11002786443835953
>>> test_bits_required(0.25)          # full intercept-resend
37

Thirty-seven. The group has 32.

With 32 test bits, a fully compromised channel — every photon intercepted and resent, QBER 0.25 — does not produce a 95% confidence interval that excludes the abort threshold. The lower bound sits at about 0.10, just under the line.

The group's protocol, as configured, cannot rule out total compromise at the confidence level they implicitly claim.

That is a narrow miss, and narrow misses are the dangerous kind: 37 and 32 are close enough that the choice looked like a rounding decision rather than a security parameter.

Step 2: the number is worse than it looks

The 37 assumes the strongest possible attack, which is the easiest one to detect. A subtler Eve is much harder:

   fraction tapped     QBER  above threshold?  test bits to detect
              1.00   0.2500              True                   37
              0.60   0.1500              True                  307
              0.50   0.1250              True                 1875
              0.45   0.1125              True                62761
              0.30   0.0750             False                NEVER

The scaling is brutal because the confidence interval must exclude a fixed threshold while the signal shrinks toward it. At $f = 0.45$ the QBER is 0.1125 against a threshold of 0.1100 — a gap of 0.0025 — and resolving that at 95% takes 62,761 test bits. The group's entire block is 800.

And below $f = 0.30$ no number of test bits helps, because the QBER is genuinely below threshold.

Step 3: the part that is not a flaw

Here the referee's question turns constructive, and the group's initial reaction — that their protocol is broken — is wrong.

Below the threshold, the protocol is still correct. Privacy amplification is sized to remove exactly what an adversary at the observed QBER could know. If Eve taps 30% and the QBER comes out at 0.075, the protocol compresses the key by the corresponding entropy, and what survives is still secret.

The threshold does not mean "Eve detected." It means "no key survives." Below it, an eavesdropper costs you key length, not security.

So the group's real error is not that they missed an attacker. It is that they reported a detection claim their statistics do not support, when what their protocol actually provides is a bound on what an eavesdropper could know, which is a different and better claim.

Step 4: the finite-key problem underneath

The referee's second question is worse. The 11% threshold is asymptotic. At 800-bit blocks, does it apply at all?

>>> from vqelab.qkd import secret_key_rate
>>> r = secret_key_rate(0.02, block_size=800, authenticated=True)
>>> r["block_reliable"]
False
>>> r["caveat"]
'this models only QBER-estimate uncertainty; a proper finite-key analysis
corrects the smooth min-entropy and carries a security failure probability,
and is STRICTLY MORE PESSIMISTIC'

The module's own model shows a 13% key loss at $10^3$ bits from QBER uncertainty alone — and it flags that it is optimistic. A proper finite-key analysis corrects the smooth min-entropy rather than the QBER point estimate and carries an explicit security failure probability $\varepsilon$. At 800-bit blocks those terms are not a correction; they are most of the calculation.

⚠️ The group had been computing key rates with the asymptotic formula because that is the formula in every textbook diagram — including the one in §38.3 of this chapter, which says so. A formula derived in a limit is not wrong; it is silent about the regime you are in.

Step 5: what the group does

Three changes, in increasing order of how much they cost:

1. Restate the claim. "No evidence of eavesdropping" becomes "observed QBER bounds the adversary's information at $X$ bits per block; our test-bit budget cannot exclude intercept-resend at 95% confidence." Free, and more accurate.

2. Raise the test-bit budget past 37. They move to 80 test bits — 10% of the block — which excludes full intercept-resend comfortably and costs 6% of the key rate. The number reviewers look at gets worse, and the claim becomes supportable.

3. Adopt a real finite-key analysis. Tomamichel–Lim–Gisin–Renner bounds with an explicit $\varepsilon$, reported alongside every key rate. This is the expensive one — it cuts their headline rate substantially — and it is the only version that is honest at 800-bit blocks.

The paper is worse and correct.

What this case study is about

The group optimized the metric that gets reported and paid for it in the parameter that makes the metric meaningful. Test bits look like overhead because their contribution is negative — they reduce the number you publish — and their benefit is invisible when nothing is wrong.

That is the same structure as four other errors in this book:

Every one is a sample-size decision made where the sample felt like overhead. Chapter 38's version is the one where the consequence is not a wrong table.

The compensating observation, and it matters: the protocol was fine. Its security did not depend on the group's detection claim, because privacy amplification bounds Eve's information whether or not anyone noticed her. The error was in the reporting, not the physics — which is precisely the pattern Chapter 36 Case Study 36.1 identified in a completely different application.

Questions

1. The group moves from 32 to 80 test bits. Compute the key-rate cost exactly, and the largest QBER they can now exclude at 95%.
2. Why does detection cost explode from 37 to 62,761 bits between $f=1.0$ and $f=0.45$? Explain from the structure of the confidence interval, not from the table.
3. The case study argues the protocol was "fine" despite the unsupportable claim. Is that too generous? Identify a scenario where the weak detection claim causes real harm.
4. [measure] For block sizes 500, 800, 2000, and 10,000, compute the fraction of the block that must be spent on test bits to exclude intercept-resend at 95%. Plot it. What does the shape tell you about small-block QKD?
5. The hard one. The group's three fixes make the paper's headline number worse. Write the paragraph they should put in the paper explaining why their rate is lower than comparable published results — and then find a published QKD result and check which of the three fixes it applied.