On Thu, Nov 21, 2013 at 3:47 PM, George Kadianakis <[email protected]> wrote: > Trevor Perrin <[email protected]> writes: > > Because your "consensus check" format contains the number of messages > contributed by each participant, a receiver knows when the "consensus > check" of a message is incomplete and can instead calculate the digest > for that specific subset of messages.
I was thinking of something a bit different: if a message X is received before its "causal predecessor" messages, the recipient would set a timer and expect the predecessors to arrive before the timer expires; once the predecessors arrive, X's consensus hash is verified. Not sure whether X should be displayed right away, or only after its predecessors arrive (like Old Blue)? I guess that's more of a UI question. > This seems like it might work. But we should still consider some > scenarios: > > - What happens if an evil participant selectively sends a message to > n-1 participants? That is, all participants but one. > > If this happens, the n-1 participants will start including that > extra message in their consesus check, but the single participant > who was left out will not be able to calculate a proper digest. > > But I guess that's why you included the timestamp in the consesus > check [0]: So that after a while (when the missing message can't be > attributed to network latency) the client of the left out > participant will be like "hm, something weird is happening with your > transcript!". I think a timestamp isn't required for that, only local timers. Once the victim recipient learns of the existence of an "extra message" from any other participant, the victim will set a timer, and expect the extra message to arrive before it expires. The timestamp would help a silent (non-broadcasting) victim realize that everything she's seeing is causally consistent but, say, delayed 1 week. But if the victim were to broadcast periodic, empty ACK messages with consensus checks, you could maybe achieve that without timestamps. The other participants would immediately realize the victim was (unacceptably) far behind by looking at her consensus check, *or* - if the victim's ACK was dropped - the victim would observe the other participants fail to include her ACK within an acceptable time. > - What happens if the consensus check fails? You said "then this is a > security error, and the chat is shut down." but shutting down the > chat so easily might enable DoS attacks that can be triggered by a > single evil client who sends corrupted consensus digests Hmm, I *think* it wouldn't be that hard to report that "User A is reporting a different view of the chat from B,C,D,E". You could restart the chat, but if that happens repeatedly, you exclude User A? Another problem is that I'm assuming message streams are ordered *and* reliable. I believe OTR traditionally has assumed ordered but not reliable streams. Do typical OTR-supporting chat protocols drop messages often? If you have to deal with unreliable message delivery, I think you either need some sort of ack / retransmit layer, or some more complicated consensus algorithm... Trevor _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
