On Fri, Nov 29, 2013 at 3:50 AM, Мария Коростелёва <[email protected]> wrote: > > This approach reminds me more about OldBlue [...] What's the > difference?
Hi Maria, Good question. I think I had different assumptions about the underlying network, and different goals: * OldBlue assumes the network is unreliable (can lose, delay, or reorder any message). * OldBlue tries to survive this unreliability via LostMsg and Retransmit requests, so that messages eventually get delivered to the higher layer with "causal order", even if this takes awhile and newer messages get delayed awaiting arrival of lost predecessors. * OldBlue doesn't try to detect failures in "timeliness" or "connectedness" unless these violate causal ordering. In particular, these won't be detected: (A) Attacker delays all messages you receive for a week. As long as the delayed messages eventually arrive in causal order, OldBlue is happy. (B) Attacker "partitions" the group into multiple subgroups, and doesn't forward messages between subgroups. As long as messages within each subgroup arrive in causal order, OldBlue is happy. I was assuming that a "normal" message stream from any user X to user Y is ordered, reliable, and timely, and that "good users" broadcast a message to all other users. I wasn't trying to build a reliable transport layer, I just wanted background checking (ideally piggybacked on existing traffic) so any deviation from above assumptions could be detected as a "security fault". (I'm not saying I *achieved* this, I think the (A) and (B) cases need more thought, but that was the goal). Trevor _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
