[OTR-dev] open source mpOTR implementation

[Ximin Luo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey, Guy!

On 10/01/14 06:31, Guy K. Kloss wrote:
> Hi all,
> 
> there has been quite a lot of talk about mpOTR in the last couple of
> years, but it seems that there's no usable implementation available of
> it, yet. At least none that I have been able to track down.
> 
> And ... please let's not discuss any issues of repudiation of encrypted
> group chat protocols in this thread.
> 
> As far as it seems from the original mpOTR paper, there are also lots of
> specifications that still need to be nailed down. A lot in this respect
> has happened already with some draft notes collected through the
> Cryptocat project.
> 
> We've also got a need for an mpOTR implementation, and we would really
> like to build our infrastructure as far on standards as possible, and
> avoid too much self knit solutions where it comes to communication
> interactions. Therefore, I'm reaching out with this mail to gauge for
> interest within the community, and see who would have an interest in
> participating in an implementation of mpOTR. From what I've seen "out
> there", the obvious parties are
> 
> * The Crypto.cat project
> * The Guardian project
> * Jacob Appelbaum
> * Some researchers from Moscow State University
> * ... and possibly others ...

I assume the WhisperSystems people are also interested. Me and some other individuals have also been actively working on various parts of this. We'll be meeting up at RWC to talk about it some further; if you have anyone in NYC, please let me know and I'll send them some details. (And anyone else on this mailing list too.)

> 
> Anyway, I'm really keen to hear from any of you guys, and to collaborate
> on any level towards (A) a sane standard, and (B) usable implementations.
> 

As I understand, there is no consensus on what a standard should look like, or even what security properties we should aim for; until we have this nailed down IMO it would be hasty to try to implement a usable product. Implementing specific ideas that solve a certain part of the problem are good though, as long as it's done in a re-usable way that we can plug into a full solution later.

To this end, we should produce a document that formally defines potential security properties that we want. For example, the Bonneau paper mentioned in the other thread makes a start, defining forward secrecy in terms of secrets compromise and confidentiality and time. We can generalise this, and also do the same thing for any other security properties we think would be useful for mpOTR. Then, people making proposals for protocols/constructions can test them against these definitions.

> We're willing to commit with resources (time and development) towards
> this. Our initial needs are for a JavaScript as well as a native code
> implementation. And we would like to see the fruit of this effort to be
> available as open source (maybe a reference implementation) with a
> liberal enough license, so that it can be utilised by as many as possible.
> 
> Our initial brainstorming has (very briefly and roughly) resulted in a
> sequence of development steps according to the following:
> 
> * make an mpENC implementation, picking up the basic concepts of the
>   current Crypto.cat multi-party specification (but probably divert
>   a bit further from JSON-only encoding towards having a binary format
>   for individual transmitted messages, to be more compliant with the
>   current OTR approach).
> 
> * improve mpENC (mpENCv2) by implementing some kind of group key
>   agreement (e. g. Group Diffie-Hellman) to overcome the problem of
>   multiple encrypted/authenticated messages towards a single, that's
>   readable by the whole group.
> 

As I understand it, the current Cryptocat multiparty protocol[1] *does* use a single group key, but it's not deniable. I'm playing with some toy ideas that provide deniability as well as addressing other issues like transcript consistency and recovery, but doesn't use a single shared key (resulting in multiplied payload). (I'm also trying to make it as simple as possible.)

Combining those two properties seems to be very hard. But it might be beneficial to explore existing ideas in more depth, to simplify existing constructions, to gain better insight, before trying to achieve more complex do-everything solutions.

[1] https://github.com/cryptocat/cryptocat/wiki/Multiparty-Protocol-Specification

> * go through various steps implementing further details of mpOTR
>   (morphing mpENC --> mpOTR)
> 

If mpOTR is the only thing you care about, this might not be the most efficient approach. If you care about having mpENC quickly, then this could work for you, as long as you understand it may well increase the overall effort to mpOTR. And you should define what you mean by mpENC, and head directly for it, otherwise time will be wasted trying to decide which subset of mpOTR is "more appropriate" or "better".

> * ...
> 
> * mpOTR: You have reached your destination :-)
> 
> We're keen for any kind of feedback, and for any type of response
> towards this collaborative effort. I'm hoping that this out reach will
> inject a bit or momentum into the mpOTR efforts.
> 
> Any thoughts, calls, shouts, utterances of disgust ...?
> 

- -- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJS0VVkAAoJEIYN7zuPZQt58YwP/0dQNjV8wi86qwjtSkmOU5i7
4HNvQaf7AiX5v/vekK3zQruCzx9HS6RruGI/fxp9dlAw8ZvP7quasFGZNk6LggL0
9wK3Y56TywTz8lpzwkWEJadWGBqFZS81iMRQQsIFk3oFG0Rs7t7O8mgFWCUR8PdS
s3Sj2NlkOtNHrbl1I2jc3pOEjqK2LJFxGgDHkWfFfcfoX+r1vIWrKE0pFR6KMwS6
qniZjT1gSinUiX8xsVe/luxuJYBf2J3ieYOncLZUo5sMqBESC9M4lJS+JbI97t+G
FCK/xu5aoifPpiZxypIiDQujvOCfOilvFWKuB5oRweTHcFf5ZOiGl4aOoh/vdzNM
dvd/bulhKqbrgFEr3Z0R7wbkRwSQOOAdRJNY8XYeRzKZfyBrs9caHn8IxKAHn8tn
vPWOVAPDBDqzcqfie1Uo1K6eXW9v+QEMQEqU+yIg5ppK59TCdOB/QBN6bada8l85
FRvTe6bjWNBD3MymuNGF63EK2IPimO3sU4q0y4rCB5eKeNpwZ+DOG/XXBV6jlMEE
+xlofWlOyfPVn35NytU64ZxaPgZBGMUfWb879wqH2TIfRI+hB2Z+BYfxpadSsI6D
bgyFDnEPp4bn6yZMCOaFCxj26/UD0bUlMOPOMF6+mwRIdql4qJA4ukQBUiFcz/Ah
Bm3eBBAoDo+6MuJwQPJn
=urKt
-----END PGP SIGNATURE-----