# computationally infeasible jobs for MITMs (Re: Secure phone)

```

John Deters <[email protected]> writes:
> It would be easy enough to "trick" the MITM into exposing their
> existance anyway, just by using digits that come up in conversation.
> Humans would be able to come up with unique situations that the MITM
> would find all but impossible to predict.  "Hey, Eric, I noticed
> that the third digit of your IP address' second octet is the same as
> the second digit of our exchange.  How's by you?"  A sudden dropout
> of sound (or "accidental" loss of connection) while the MITM
> recognizes the trap and tries to backpedal will be instantly
> noticed.  Human protocols are resilient, whereas mathematical
> protocols are precise.

I wonder if we can come up with a way to formalise this technique and
automate it.  I think it was James voiced something similar earlier in

Using your example, the MITM faces a couple of problems: he has to
think on his toes, and think real fast.  Perhaps he can't think fast
enough.

Second problem, perhaps if he doesn't speak soon enough, he will have
blown it, because you are speaking continuously, and the second part
of the sentence constructs a problem from information already stated.
The first time the information is stated, the MITM doesn't have enough
information to change it.

Say he changed it to: "Hey eric I noticed the second digit..." (second
instead of third), just in case this would help him.  Well he doesn't
know what the challenge will be so he may just have created an
impossible to spoof problem for himself.  (The second digit probably
won't meet the challenge in the second part of the sentence).  So this
would force the MITM to construct a replacement challenge which does
match.  Given the short notice, and already decided first part, he may
have difficulty constructing a plausible sounding challenge which
meets his criteria.  "Is the ummm... square of your first digit".

of the game: to make the MITMs job computationally infeasible.

Say that we leave some noise in the speech channel.  Some of it isn't
really noise but encrypted data.  Say perhaps first stegoed packet is:

E(k1, nonce) = packet1

and second stegoed packet is:

E(k2, nonce) = packet2

and finally there is a mask which controls which bits of the noise are
actually encrypted data, and which are parts of the actual message.

Send this last:

Then send the three keys k1, k2, k3.

Then check that the packets1 and 2 reconsituted according to the mask
both decrypt to the same nonce.

The idea is that because of the mask, the MITM doesn't know which bits
to replace.  So he tries to construct his own challenge meeting that
protocol.  Fair enough he can do this.  But he will degrade the voice
quality because he will replace some more signal with noise.  Can we
tune this protocol so that the recipient can detect the extra noise?

Well, ok, if the recipient can detect the noise, surely the MITM can
too?  Yes but, choosing different bits to reduce the noise isn't free,
and the hope is that you can construct a system with an expensive
noise estimation function which is agreed to as part of the protocol.
So you find out 10 seconds into the conversation that there is a MITM.

The MITM has to compute this noise function in real time, to avoid
introducing lag.

It's not very good, but I'm sending it along anway, so that perhaps
y'all can improve on it,