[OTR-dev] Achieving non-non-repudiation in another protocol.

Gregory Maxwell gmaxwell at gmail.com
Wed Aug 27 11:20:20 EDT 2008


On Wed, Aug 27, 2008 at 10:17 AM, Ian Goldberg <ian at cypherpunks.ca> wrote:
>> Does this appear correct?
>
> I think you indeed achieve repudiability, but I'm pretty sure the above
> protocol suffers from the same identity-misbinding attack that OTRv1
> had.
>
> The MITM can change the signature on the last message to be her own
> signature instead of C2's.  Then C1 will think she's talking to MITM,
> but she's really talking to C2.

Eeek. I agree. Thank you for pointing this out.

> OTR switched to the SIGMA protocol (used in IPSec) to overcome this
> problem.  I think to fix the above, you could:
>
> - Change the H inside the signatures to a MAC, with key based on the DH
>  shared secret.  This proves that the parties have computed the same
>  session key.
> - Put the sender's name/id/pubkey inside this MAC, along with the M and
>  N values.

I had consciously avoided *signing* the DH value or any result of the
DH value because I wanted a third party to be able to produce a whole
encrypted transmission bearing client1 and client2's signatures based
only on passive observation without ever taking to those clients
himself. Since the third party wouldn't know the private portions of
the DH exchange (nor could we reasonable expect him to find new a new
DH exchange which resulted in the same shared secret, I think) signing
the DH exchange or shared secret would prevent such an forgery.

I think I can probably solve this by including the pubkey inside the
initial MAC over the public DH values but I'll have to give it a bit
more thought.

Thank you very much for your insight.



More information about the OTR-dev mailing list