[OTR-users] Question About OTR Security

[Paul Wouters]

On Tue, 24 Apr 2012, rookcifer wrote:

> Date: Tue, 24 Apr 2012 05:10:11
> From: rookcifer <rookcifer at gmail.com>
> To: otr-users at lists.cypherpunks.ca
> Subject: [OTR-users] Question About OTR Security
> 
> I saw a paper entitled "Finite-State Security Analysis of OTR Version 2"
> by two researchers at Stanford.  In the paper they describe a couple of
> potential security flaws with OTR.  From the abstract:

> So my question, have these attacks been addressed and has the advice of
> the paper's authors (in relation to strengthening of the protocols) been
> applied?

See:

To: otr-dev at lists.cypherpunks.ca
Subject: Re: [OTR-dev] Draft of Security Analysis
From: Ian Goldberg <ian at cypherpunks.ca>
Date: Mon, 6 Mar 2006 21:45:09 -0500

On Mon, Mar 06, 2006 at 04:35:35PM -0800, Andrew S. Morrison wrote:
> We wanted to send along the draft of some of the results of our security
> analysis before we give a talk on it in a few days in hopes we could get
> some comments. We believe we've found a few good attacks.
> 
> http://www.stanford.edu/~amo/DRAFT_otr_analysis.pdf
> 
> The paper is just a draft right now. We're hoping some people on this list
> could take a look at the "Attacks Found" section and read through to make
> sure the attacks are legitimate. After a round of getting comments from
> you guys and some others we'll send the final version of our paper and the
> Murphi code we used to model OTR. That'll be in about a week and a half.

I took a (very) quick look, but I'll be travelling tomorrow, and may not
have email access again before your talk.

3.1 Version Rollback

     Version rollback, I think, is only a serious concern when it's
     invisible (in SSL, for example).  In OTR (at least the gaim-otr UI;
     I can't speak for the others), it's clear when you're sending and
     receiving encrypted messages, and when you're not.  Additionally,
     it's made clear when you're using version 1 of the protocol, so you
     can take the precaution of asking your buddy to say her name.

3.2 Attack on Strong Deniability

     The attack relies on Bob publishing incorrect MAC keys.  But that
     doesn't make sense; Bob publishes the MAC keys in order *to protect
     himself*.  Intentionally publishing incorrect ones (or, he may as
     well just not publish them at all) would only serve to weaken his
     own deniability.  Note also that Alice and Bob each publish the MAC
     keys, so they'd *both* have to be intentionally trying to make their
     own conversation not deniable.

3.3 Message Integrity

     Good call on this one.  Bizarrely, it doesn't turn out to be a
     security hole in the deployed software because there's a bug in it. (!)
     The deployed software only publishes MAC keys that were used to
     receive messages, not ones on messages it sent.  This is safe,
     because it knows for sure that it'll never trust a MAC key that it's
     already published.  I also believe that even if Bob is cheating, and
     doesn't publish any MAC keys, but only Alice publishes the MAC keys
     of the messages she receives, they still get strong deniability:
     Mallory can take one of the messages Alice received (and
     subsequently published the MAC key for), and substitute a g^y of his
     choosing.  He can then recompute the keys and MACs for future
     messages in the transcript.  [It's late, and I'm doing this quickly,
     so I don't guarantee this is correct.  I'll think about it some more
     in the next couple of days.]  Assuming this is correct, you indeed
     found a problem with the spec, but not in the implementation,
     because the implementation turns out to be more secure than the
     spec.

3.4 Authentication Failure

     I don't see the problem here.  Alice believes she's talking to Bob,
     because she *is* talking to Bob.  If Mallory is passing messages
     through unmodified, she may as well be a wire.  It's not a security
     problem if Mallory sees encrypted messages, and her being able to
     stop Alice and Bob from talking to each other is just a Denial of
     Service attack, which we explicitly don't care about.


Thanks for the analysis!  Feel free to email me or the list with any
questions, comments, or radical doubts.  ;-)  [Though, as I mentioned, I
may or may not have email access from Tuesday morning to Thursday.]

    - Ian
_______________________________________________
OTR-dev mailing list
OTR-dev at lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev