Difference between revisions of "Thread:Talk:MpOTR/Rename "broadcast scheme""
(New thread: Rename "broadcast scheme") |
m |
||
| Line 2: | Line 2: | ||
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. | 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). | ||
Latest revision as of 15:53, 2 August 2014
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).
