This raises an interesting point about "tamper revealing" methods of security. Open source, publicized hashes of executables, even key exchange protocols, all of these prevent attacker tampering by making it more likely attacks (or even just bad code) will get noticed. They don't strictly prevent tampering, they discourage it.

Take DHKE. It "defends" against MITM. But it doesn't strictly prevent it. An attacker could perform the protocol with both Alice and Bob separately, then guard the line and tamper with any communications on that channel that attempt to confirm the shared secret. The attacker couldn't win against a determined Alice and Bob, though, because A&B could theoretically use other channels, or even publicly broadcast some confirmation of the shared secret. So the smart attacker is "probably discouraged" from the noisy MITM.

But how many key exchange implementations actually use separate (availability ensuring) channels to confirm no one is in the middle? It's prohibitively expensive to verify no one's attacking something that no one ever attacks.

But then again, things no defender verifies are attractive to attackers. And some attackers are willing to get noticed 9 times out of 10 to land the one payout. "Tolerance for getting caught" is not always zero, that's another variable that complicates our Nash equilibrium here...