[OTR-dev] open source mpOTR implementation

[Guy K. Kloss]

Hi Ximin, Ian, Nadim and everybody else,

On 12/01/14 03:30, Ximin Luo wrote:
> 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.)

Sorry, we don't have anybody in NYC at the moment. But I really like the
idea of getting together and sussing things out. I'd be keen to stay in
the loop on this myself, though.

> 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.

Fully agreed, see below for more on that.

> 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.

So basically revisiting the Goldberg mpOTR paper, substantialise and
more closely define aspects, and use that as a basis for proposals on
what implementation primitives to use for it (e. g. what crypto
primitives to use).

> 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.)

Are you sure about the single group key? Looking exactly at your
reference [1] (draft versiom 2.3.6), at the end of Sect. 3, the
"Message" definition states a JSON object payload that contains
individual cipher texts and HMACs for every recipient ... So there are
shared secrets, but they seem to be pair-wise shared secrets
(`sharedSecretNM`). Maybe the actual current *implementation* uses a
group key, but that's not what I've been able to read from [1].

> 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".

Indeed, mpOTR is not the main focus. We're aiming at a secure,
reasonable and (community) accepted implementation. So mpENC is just a
mile stone on the path, in order to be able to cut the "time to market"
down for us. So it's just a stepping stone, but it can also be a nice
intermediate to already break an implementation towards agreed upon
specification decisions from mpOTR. In the end, we'd hate to put out
something that's a one-off hack by one commercial entity, if it goes
against the grain of what the community wants/needs. But we'll just need
to find an intermediate sub-set (mpENC) that can be evolved towards
whatever comes out of the mpOTR discussion (or wherever that's going to
evolve to).

Thanks for the feedback so far, and feel free to get in touch with me.
We're willing to be a good community player and pull on the same end of
the rope as the rest.

Guy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20140113/45729a31/attachment.pgp>