learn.equalit.ie

This is a threaded discussion list to collate all discourse on protocol creation, adversarial models, et al. Should you wish to contact us directly by email, please use http://equalit.ie/#contact

• [View source↑]
• [History↑]

Sorting order: last modified first newest threads first oldest threads first

Contents

Thread title	Replies	Last modified
Rename "broadcast scheme"	1	23:14, 2 August 2014

First page

Previous page

Next page

Last page

Rename "broadcast scheme"

• History
• Summarize

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.
• You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

---

You can view and copy the source of this page:

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

Return to Thread:Talk:MpOTR/Rename "broadcast scheme".

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.

• Parent
• More

• History
• View source
• Link to

Vmon (talk)‎23:14, 2 August 2014

 

First page

Previous page

Next page

Last page