-----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----- _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
