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

[Nathan of Guardian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/22/2014 09:11 AM, Ximin Luo wrote:
> On 22/01/14 13:43, Nathan of Guardian wrote:
>> 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.

We have already been thinking along these lines using private
messaging within XMPP MUC, and as a general one-to-many "secure
broadcast" option.

- - A wants to send an alert/broadcast message encrypted to B and C, and
view their responses in an inline "virtual" group. B and C only
establish an OTR session with A.

This is just hacking around the existing protocols to create different
user experiences. The pair-based model makes this work inline within
one shared communications channel, without any new user experience
(fundamentally), and if verification state of key fingerprints can be
tied into existing identities / trust established in one-on-one chats,
then that is also useful.

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

Jitsi's implementation is unique to encrypted audio, since it can be
mixed together. If A0 is the hub, they originate separate SIP calls +
ZRTP session with B0 and C0. As audio comes in from C0 to AA, it is
mixed with A0's existing encrypted audio stream. In addition, if A0
calls A1, who has their own existing conference call setup with B1 and
C1, the two A "hubs" will proxy all the encrypted audio from their
respective B and C "spokes", and you end up with a 6 member encrypted
call.

Again, I think this only works with audio, but I had been thinking
about the possibility of message or arbitrary data proxying within
existing OTR protocols.

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

Virtual MultiParty
Segmented Multi Party
Many-One-to-One (MOO!)

Pair-based is fine, as well, once it is explained. Thanks.

+n




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS3+H5AAoJEKgBGD5ps3qpLHgQAJqnpJotCBS8zBdgLWZKUzvp
mooAAbdTBusWCRh7Uk2W0NUoTnbwuVv7Nm7WccBDE4fXZWXeu5PpfHvJrKj0sDeC
uOcNQOJGYttzfn9DKBYO+vxQ9LAXYSALSjaNscTwVKH5fBX5Q15+CMCYuU9b0lLP
siH8OM6NBTI/wscfAvp6/pAxWHM7iffKrCa6nM8ndLsgnuSpfakznhqBhjf+pL5l
trA3szEnBQW0S6lMfygaVKTJB1otoRwJqh66VZ1ItAkxaZ9Qme1NO1O1yXQMDqeo
7ogHzGViAPcjwnLnX0Ejwv0malusWHysiqNBjM2yunw+97o6cEbi3V742TRHzJef
Lqd69vdd1rchcXm91T3tGYEq/+BJxOSLtbGG6SOaWkttRxFwbtEQ1b8Cxv30E29n
foS6nuUSLkc7Kzyt5bwriRYQeA4EUP2j1oTtXI53sZzXLH+QblCrM/0946dxV+3L
eYoT+f4G/KWdwytw5rQdobbWH1NQUcXKdJjKa5YF8bPEDQQaIwgGSpeh+eWhH9ox
WcQRu0yT0EZCZ2I4R8AxIs95gdWqhte6XGtEOifuwN5PEZbuazec9Eze7nkhQOJa
vi7VErErYtvJuQunTnglcD6ZXDy3KOZv2Zv9wwl2NVaVvLbcac9dxDmsrEi/dEwx
KzewXPR/u7hk9Ldo4GPN
=Dmyb
-----END PGP SIGNATURE-----