Thread history

From Talk:MpOTR/Overview
Viewing a history listing
descTime User Activity Comment
23:14, 2 August 2014 Vmon (Talk | contribs) New reply created (Reply to Rename "broadcast scheme")
15:53, 2 August 2014 Infinity0 (Talk | contribs) Comment text edited  
15:50, 2 August 2014 Infinity0 (Talk | contribs) New thread created  

By "broadcast scheme", this refers collectively to the peer-to-peer pairwise broadcast, or the "sender keys" optimisation on top of it. I think "broadcast scheme" is too generic and confusing. How about "p2p-broadcast", "full-broadcast", "sender-broadcast", or "member-broadcast"?

I also disagree with "Each participant will have its own different $plist_i$ which is able to broadcast too.". In all schemes, every member should eventually reach the same plist as everyone else. In all schemes, there will be a period where different members have different plists - e.g. even in the GKE case, some members will receive the final round of the GKE earlier than others, so switch to the new plist earlier than those others.

The key difference is that in the p2p-broadcast case, (optionally) members are able to *provisionally send* to the new plist earlier than some other members do, without receiving a key confirmation (and with a forward secrecy penalty if there was an active attack).

Infinity0 (talk)15:50, 2 August 2014

I don't think any of those schemes are fundamentally different. The fundamental difference in threat model (and in implementation) is can we start sending message before everybody a reach same view of the room or not.

Original mpOTR doesn't allow it and it is much simpler in implementation and we have security proof for it. My guess is that it doesn't make a huge difference in user experience in majority of xmpp usages. It is also not hard to tweak the code and algorithm to fall back to the different view scenario, that is why I prefer to go with that.

Vmon (talk)23:14, 2 August 2014