<div dir="ltr"><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px">Hi everyone,</div><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px">
I have a question considering the topic of this converstion. </div><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px">
If we have a situation like this:</div><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px"><span style="color:rgb(34,34,34)">>> At some point t_0, it so happens that A and B each send a message (m_a</span><br style="color:rgb(34,34,34)">
<span style="color:rgb(34,34,34)">>> and m_b) to all other participants at approximately the same time [0].</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">>> At t_0, the internal transcript state of A, B and C is the same.</span><br style="color:rgb(34,34,34)">
>><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">>> When C receives m_a, the consensus check matches and C updates her</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">>> internal transcript state to include m_a.</span><br>
>> Now, when C receives m_b, the consensus check won't match since the<br>>> internal transcript state of C includes m_a, while the consensus check<br>>> of m_b doesn't (B was not aware of m_a when m_b was sent and hence it<br>
>> was not included in its consensus check).<br>>></div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">> That's OK.  m_b's consensus check doesn't have to include every</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">> message in C's transcript, it just has to be consistent with C's</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">> transcript.  Which it is!</span><br><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">how exactly C checks the consistency of </span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">m_b's consensus check?  I didn't get this explanation by Trevor:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px">> On Thu, Nov 21, 2013 at 3:47 PM, George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>> wrote:<br>
>> Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> writes:<br>>><br></div><div class="im" style="font-family:arial,sans-serif;font-size:13.333333969116211px">>> Because your "consensus check" format contains the number of messages<br>
>> contributed by each participant, a receiver knows when the "consensus<br>>> check" of a message is incomplete and can instead calculate the digest<br>>> for that specific subset of messages.<br>
>></div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">> I was thinking of something a bit different: if a message X is</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">> received before its "causal predecessor" messages, the recipient would</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">> set a timer and expect the predecessors to arrive before the timer</span><br style="font-family:arial,sans-serif;font-size:13.333333969116211px">
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px">> expires; once the predecessors arrive, X's consensus hash is verified.</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Maria</span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br>
</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/26 Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Nov 21, 2013 at 3:47 PM, George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>> wrote:<br>
> Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> writes:<br>
><br>
</div><div class="im">> Because your "consensus check" format contains the number of messages<br>
> contributed by each participant, a receiver knows when the "consensus<br>
> check" of a message is incomplete and can instead calculate the digest<br>
> for that specific subset of messages.<br>
<br>
</div>I was thinking of something a bit different: if a message X is<br>
received before its "causal predecessor" messages, the recipient would<br>
set a timer and expect the predecessors to arrive before the timer<br>
expires; once the predecessors arrive, X's consensus hash is verified.<br>
<br>
Not sure whether X should be displayed right away, or only after its<br>
predecessors arrive (like Old Blue)?  I guess that's more of a UI<br>
question.<br>
<div class="im"><br>
<br>
> This seems like it might work. But we should still consider some<br>
> scenarios:<br>
><br>
> - What happens if an evil participant selectively sends a message to<br>
>   n-1 participants? That is, all participants but one.<br>
><br>
>   If this happens, the n-1 participants will start including that<br>
>   extra message in their consesus check, but the single participant<br>
>   who was left out will not be able to calculate a proper digest.<br>
><br>
>   But I guess that's why you included the timestamp in the consesus<br>
>   check [0]: So that after a while (when the missing message can't be<br>
>   attributed to network latency) the client of the left out<br>
>   participant will be like "hm, something weird is happening with your<br>
>   transcript!".<br>
<br>
</div>I think a timestamp isn't required for that, only local timers.  Once<br>
the victim recipient learns of the existence of an "extra message"<br>
from any other participant, the victim will set a timer, and expect<br>
the extra message to arrive before it expires.<br>
<br>
The timestamp would help a silent (non-broadcasting) victim realize<br>
that everything she's seeing is causally consistent but, say, delayed<br>
1 week.<br>
<br>
But if the victim were to broadcast periodic, empty ACK messages with<br>
consensus checks, you could maybe achieve that without timestamps.<br>
The other participants would immediately realize the victim was<br>
(unacceptably) far behind by looking at her consensus check, *or* - if<br>
the victim's ACK was dropped - the victim would observe the other<br>
participants fail to include her ACK within an acceptable time.<br>
<div class="im"><br>
<br>
> - What happens if the consensus check fails? You said "then this is a<br>
>   security error, and the chat is shut down." but shutting down the<br>
>   chat so easily might enable DoS attacks that can be triggered by a<br>
>   single evil client who sends corrupted consensus digests<br>
<br>
</div>Hmm, I *think* it wouldn't be that hard to report that "User A is<br>
reporting a different view of the chat from B,C,D,E".  You could<br>
restart the chat, but if that happens repeatedly, you exclude User A?<br>
<br>
Another problem is that I'm assuming message streams are ordered *and*<br>
reliable.  I believe OTR traditionally has assumed ordered but not<br>
reliable streams.  Do typical OTR-supporting chat protocols drop<br>
messages often?<br>
<br>
If you have to deal with unreliable message delivery, I think you<br>
either need some sort of ack / retransmit layer, or some more<br>
complicated consensus algorithm...<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Trevor<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OTR-dev mailing list<br>
<a href="mailto:OTR-dev@lists.cypherpunks.ca">OTR-dev@lists.cypherpunks.ca</a><br>
<a href="http://lists.cypherpunks.ca/mailman/listinfo/otr-dev" target="_blank">http://lists.cypherpunks.ca/mailman/listinfo/otr-dev</a><br>
</div></div></blockquote></div><br></div>