[OTR-dev] mpOTR and the road ahead ...?

[Ximin Luo]

On 22/01/14 13:43, Nathan of Guardian wrote:
> Ximin Luo <infinity0 at pwned.gg> wrote:
> 
>> Away from the overall mpOTR discussions, I spent a lot of time on the
>> side talking about forward-secrecy ratchets with Trevor. We also talked
>> about the advantages and disadvantages of a pair-based system. (This is
>> opposed to a group-based system that most others are thinking about).
>> We and some others think it would be worth pursuing this further, with
>> the understanding that this would not scale to massive groups. Despite
>> this, the advantages are:
> 
> When you say pair-based, does this mean proxying between pairs to build up a secure group? Perhaps this is similar to what Jitsi does for encrypted conference calls (though through audio mixing), which I have been calling "hub and spoke"?
> 

It means that every sender sends each message encrypted separately to each receiver. Proxying *might* occur (not yet decided if this is a good idea), e.g. in the following case:

- we have a broadcast model, so when A sends a message, it contains the text encrypted to each person separately.
- B receives this message and decrypts the portion intended for himself. Later, he is asked to re-send the ciphertext to C. The message also contains the portion encrypted to C, who can deduce that the author is A.

but this doesn't sound like what you mean by "hub-and-spoke".

Maybe I should think of a better phrase. (Also I should clarify that "opposed to" should've been "as opposed to" or "in contrast to", I'm not against the group-based solutions.)

> Regardless, from a use case perspective what ChatSecure users tend to ask for more (now that we have XMPP MUC support) is to have small group, short term encrypted chats (scrums, planning meetings, business discussions) as opposed to large scale persistent secure discussions. 
> 
> There is an inherent cognitive dissonance between the idea of a private chat and a say a group of more than 10 or 20 people.
> 
> As for concrete solutions, up until recently I have been considering adopting CryptoCats existing Android mpOTR implementation just to show interop is possible. I wouldn't want that to be seen as a snub to any of these efforts however, and the pair-based approach seems like one we would like to support as well, in an interim way.
> 
> Happy to see the outcome of RWC and sorry we missed it. 
> 
> +n
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

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