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

[Ian Goldberg]

On Wed, Aug 27, 2008 at 11:20:20AM -0400, Gregory Maxwell wrote:
> 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.

Fair enough; you just have to MAC your name with the DH session key, and
also sign something fresh.  So S(N1 || N2), MAC_s(my name) where s is
derived from the DH shared secret may be OK.  (That is, I think the MAC
doesn't have to be *inside* the signature.)  I think that's one of the
variants explicitly given in the SIGMA paper, but I'm not positive.

   - Ian