MUC encryption plugin

[Ethan Blanton]

Sebastian Lechner spake unto us the following wisdom:
> I have some questions regarding end-to-end encryption in pidgin. I know
> that there are plugins (OTR, OpenPGP) that enable pidgin users to
> encrypt one-to-one conversations. As far as I know no plugin supporting
> MUC encryption has been developed yet though. Am I correct?
> 
> The amount of time I've invested into the search for FLOSS programs
> supporting end-to-end encryption for chat rooms suggests that they must
> be very rare in general. Crypto.cat is the only example I can name at
> the moment. It offers secure chat rooms for up to 10 people. I am not to
> enthusiastic about it requiring a browser for execution as well as being
> written in JavaScript though.

It is very rare because it is a very hard problem.  If you intend to
have any sort of forward secrecy, you have to rekey the entire chat
*every single time* someone joins or leaves.  If you don't want to
trust the server (which you should not), that rekey must involve every
member of the chat.  If you want to have confidence that your
communications are not being eavesdropped upon, every member of each
chat must authenticate the key of every other member each time the
membership changes (which may be "free" with the keying protocol,
depending on what you choose, but still requires copious amounts of
human-driven key management).  If an untrusted user attempts to join a
chat, you have to have a way to reject that without losing
communication between the existing members.  You probably want a way
for an existing member to "introduce" a new member who is not trusted
by every other user.  The list goes on and on.  For each of these
items there does exist a cryptographic solution, but for some it is
quite expensive (multi-party keying with PFS, for example) and for
others it requires a critical level of user involvement
(e.g., authentication of new keys) above and beyond what two-party
communication typically requires.

Then there's working around whatever limitations you're given with an
off-the-shelf IM protocol.  For example, does it provide total
ordering with respect to joins and parts and channel messages?  How
large a message can you send, and what are the rate limits?  Again,
all things that can be worked around, but not necessarily simply.

Personally, I am confident that such a protocol can be built,
particularly if you restrict yourself to "friendly" protocols (such as
XMPP) and if you can leverage external trust mechanisms (such as PGP)
to at least some extent.  (Notice, however, that PGP "trust" means "I
believe that this key belongs to this individual", not "I would
include this user in my secret chats" -- so you still need your own
layer of authorization, even if you can defer authentication.)

> Some groups working on liberatory social change (covering topics such as
> human rights or animal rights) to which I belong or that I know of use
> Pidgin and one of the above plugins for secure one-to-one communication
> (in combination with Tor) to make it harder for repressive authorities
> to monitor them. I know that many of the activists known to me would
> really appreciate secure group conversation too.
> 
> Turns out that to attain a Bachelor's degree in computer science I will
> have to implement a security-related program, so I am planning on
> writing a MUC encryption plugin for Pidgin based on OpenPGP or OTR (I
> have not taken a decision on the encryption system yet). I've mostly
> developed stuff in object-oriented languages so far, but I'm quite
> fluent in C also.

Neither PGP nor OTR is an "encryption system" that is really
appropriate for this task.  They may or may not provide some
primitives you would find useful.  I caution you that you will HAVE to
get some crypto buffs (preferably several) on board for whatever
design you propose, as it is MUCH easier to build an insecure protocol
than it is to build a secure protocol, and the two often look very
similar (if not indistinguishable) to the amateur.  Simple things like
putting a nonce in the wrong stage of an exchange or reusing a
particular value can inadvertently expose your entire exchange.

> My main questions are the following: How would Pidgin/libpurple support
> the development of a plugin of this type? How high would you rate the
> chances of success for the development of such a plugin?

We don't generally "support" third party plugins in any way, except
that we are willing to answer technical questions to the best of our
abilities.  I am not sure what sort of support you are looking for.
The chances of success depend heavily on your understanding of
cryptographic primitives and protocols, and their limitations.
Without being able to judge that understanding, I can't say -- but my
prognosis is very poor.  I think this is a very hard problem to bite
off.

That said, I think you can probably create a solution that is suitable
for a Bachelor's thesis, by constraining your requirements
appropriately.  It all depends on what you really want to accomplish.

The above is my analysis as a software developer and computer
scientist with an interest, but very little expertise, in cryptography
and cryptographic protocols.  It represents my belief of the position
of Pidgin developers in general, but of course I cannot speak for all
of us.

Ethan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20121011/5b2c59a1/attachment.sig>