OTR in Pidgin?

[Ian Goldberg]

On Wed, Jan 14, 2009 at 02:03:46PM -0800, Casey Ho wrote:
> On Tue, Jan 13, 2009 at 6:22 PM, Casey Ho <pidgin at caseyho.com> wrote:
> > On Tue, Jan 13, 2009 at 12:30 AM, Kevin Stange <kstange at pidgin.im> wrote:
> >> Casey Ho wrote:
> >>> As the survey results indicated, encrypted IM support is as popular as
> >>> VV support [1].
> >>>
> >>> How do you all feel about including the OTR plugin by default in Pidgin?
> >>
> >> There are a few reasons we've historically rejected the inclusion of
> >> such a plugin.  The most prominent is that Pidgin and libpurple have
> >> traditionally made an effort to not transmit to users anything that an
> >> official client would not, so as to assure maximum compatibility with
> >> the server and other clients, unless it can be cleanly detected in
> >> advance which capabilities users have without negative impact.  This is
> >> extended to "magic formatting" features some third party tools use, and
> >> various features that result in gibberish being transmitted in plain
> >> text to users.
> >>
> >> We would also then be responsible to choose which implementation of
> >> security we feel is best, and such an endorsement would probably
> >> effectively kill off the efforts of other plugins with other goals.
> >> It's plausible that after internal discussion, for example, we might
> >> find OTR to be the least desirable implementation but the most widely
> >> deployed and be forced to choose between supporting something we don't
> >> like versus something relatively few care to use.  If we are interested
> >> in supporting an encryption plugin, this investigation would need to happen.
> >>
> >> Since such plugins are not currently maintained by us, it demands we
> >> adopt a set of developers and force them to comform to our development
> >> cycle and tools, which may not be of interest to them.  I can't imagine
> >> that most our own developers wish to be tasked with maintaining a new
> >> chunk of code they've never previously reviewed.
> >>
> >> From my experience with OTR as well, I think it would require a major UI
> >> redesign before I would want to subject our users to it.  Perhaps some
> >> of those shortcomings currently are due to failings of our API, which
> >> could be fixed.
> >>
> >> I think it's better to focus on making plugins easier to locate,
> >> distribute and install.  I'm not sure I would want such a heavy plugin
> >> distributed in Pidgin proper that we'd be forced to begin supporting
> >> when there are already other people out there seemingly happy enough to
> >> do it on their own terms.
> >>
> >> I know that developers have expressed problems with the designs of some
> >> of the encryption plugins in discussions that have come up before.  I'm
> >> sure they'll pop in with their comments.
> >>
> >> Kevin
> >
> > [+ Ian Goldberg, who is the lead for OTR]
> >
> > From a cryptography standpoint, OTR appears to be the best solution
> > available.  Pidgin-encryption does not offer a mechanism for secure
> > key exchange, whereas OTR uses Diffie-Hellman.  Pidgin-Paranoia uses
> > one time pads, which have historically been vulnerable because no
> > computer can be truly random.  One weakness of the protocol is that it
> > could theoretically be blocked from the networks.  This hasn't
> > happened, but it would be feasible.
> >
> > From a usability standpoint, Pidgin-OTR is not the best solution
> > available.  The menus and buttons work reasonably well for the
> > simplest case- two OTR-enabled clients communicating.  However,
> > exception cases aren't handled as well- usually this involves the
> > conversation being closed and restarted, or having one of the parties
> > trying to communicate with encryption disabled.  There's definitely
> > some work to be done here, but it seems relatively lightweight when
> > compared to the task of developing a well secured protocol.  The OTR
> > team appears to be aware of at least some of these issues.
> >
> > From a development standpoint, OTR is written as part of a research
> > project.  Kevin is right when he says that there's a completely
> > different development cycle from Pidgin.  That said, the protocol
> > appears to be relatively stable and does not need major updates
> > (good).  I agree with John's point that libotr (the most complex part)
> > should be kept as an optional external dependency.
> >
> > -Casey
> 
> So after some additional testing, I believe this should be tabled.
> 
> I was able to cause serious problems if a contact is logged into two
> OTR enabled clients at once with two different sets of keys.  The
> clients become confused- OTR tries to handshake with both at once, and
> while one handshake succeeds, the other fails and the handshake fails.
>  Then the handshake process repeats.  End result- lots of garbage
> messages being spammed around.
> 
> This is a pretty serious deficiency, and after some thinking about it,
> I don't think there's an easy solution.

As it turns out, I had a student write a fix to this last term.  I just
haven't had a chance to integrate it into the main code yet.

   - Ian