OTR in Pidgin?

[Casey Ho]

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.

-Casey