The Odds a MITM Guesses the Comparison Code

The Odds a MITM Guesses the Comparison Code

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

The Odds a MITM Guesses the Comparison Code

During Numeric Comparison pairing a smart lock and a phone both display 481923 while a man-in-the-middle can only show its own 775204, so an undetected attack needs the tampered transcript to reproduce the same 6-digit code — 1 in 1,000,000. Even across the 10 retries a user might tolerate, the chapter still puts the risk at 0.001%, essentially zero. This audit re-derives that figure at full precision and asks whether the ten-retry shortcut hides anything, or whether the protection really is the vanishing odds of matching the code.

Companion to the chapter BLE Pairing and MITM Defense — every number here comes from that chapter.

Try

During Numeric Comparison pairing a smart lock and a phone both display 481923 while a man-in-the-middle can only show its own 775204 , so an undetected attack needs the tampered transcript to reproduce the same 6-digit code — 1 in 1,000,000 . Calculate this case.

Observe

This audit re-derives that figure at full precision and asks whether the ten-retry shortcut hides anything, or whether the protection really is the vanishing odds of matching the code. Check shows this.

Explain

The chapter's 10 / 1,000,000 = 0.001% is the union-bound approximation; it overstates the true value by only 4.5 x 10^-11, so to the displayed precision the two agree. The design meaning is that the protection is not the secrecy of the code -- it is shown openly on both screens -- but the vanishing chance that a tampered transcript reproduces it: each retry the user toleratesraises the cumulative chance nearly linearly. Check confirms it.

See the relationship before changing it

The chapter figure below shows: Numeric Comparison Authentication Stage 1: Device A and Device B each choose a random nonce, Device B computes a confirmation value from both public keys and its own nonce and sends it first, the two nonces are exchanged next, Device A verifies the confirmation and aborts on mismatch, both devices then compute a six-digit value from the shared public keys and nonces, and the user compares the two displayed values before pairing proceeds.

Numeric Comparison Authentication Stage 1: Device A and Device B each choose a random nonce, Device B computes a confirmation value from both public keys and its own nonce and sends it first, the two nonces are exchanged next, Device A verifies the confirmation and aborts on mismatch, both devices then compute a six-digit value from the shared public keys and nonces, and the user compares the two displayed values before pairing proceeds.

Derive the baseline in four named moves

1. 1

   Name the input. The chapter baseline is 10 attempts.

2. 2

   Name the relationship. chance = (1 - (1 - 1/1,000,000)^attempts) x 100

3. 3

   Substitute with units. 10 attempts give 0.001000%

4. 4

   Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.

Predict, then change pairing attempts

Try Predict how at-least-one match chance responds when pairing attempts moves. Calculate pairing attempts; compare at-least-one match chance with that prediction.

Pairing attempts

10 attempts

Chapter baseline

At-least-one match chance

Observe Return to 10 attempts. Recheck at-least-one match chance with pairing attempts at its chapter value.

Explain Each independent retry adds almost one chance in a million.

Check yourself

What should you do before trusting a moved-slider result?

Answer: Predict its direction, apply the displayed relationship, keep the units, and compare the reset value with the chapter’s worked baseline.

What does this small model leave out?

Answer: Only pairing attempts moves here. The at-least-one match chance calculation excludes field effects listed below.

Honesty note. The at-least-one match chance result holds pairing attempts as the only changing input. It is not a field prediction.

Technical boundaries

The chance calculation assumes independent, uniformly random guesses of a six-digit comparison value. It does not model people overlooking a mismatch, biased randomness, how sessions repeat, protocol defects, or information leaked through side channels.

Ada: The chapter pins Numeric Comparison’s strength on a 1 in 1,000,000 code match and adds a 10-attempt figure. Let me verify both and be precise about the 10-attempt case, since the ten-retry estimate is a slight shortcut.

A six-digit comparison value has 10^6 = 1,000,000 possibilities, and an active relay that swaps in its own public keys must have its tampered transcript coincidentally produce the same displayed code:

• One attempt: P = 1 / 1,000,000 = 0.000001 = 0.0001%.
• Ten independent attempts, the exact probability of at least one match: 1 - (1 - 1/1,000,000)^10 = 9.99996 x 10^-6 = 0.001000%.

The chapter’s 10 / 1,000,000 = 0.001% is the union-bound approximation; it overstates the true value by only 4.5 x 10^-11, so to the displayed precision the two agree. The design meaning is that the protection is not the secrecy of the code – it is shown openly on both screens – but the vanishing chance that a tampered transcript reproduces it: each retry the user tolerates adds only about one in a million, so even ten retries leave the attacker near 0.001%, essentially zero.

Every number above is taken from the chapter’s own material and re-derived step by step.