[OTR-dev] Ensuring transcript soundness in a multiparty chat setting

[Мария Коростелёва]

Hi everyone,

I have a question considering the topic of this converstion.

If we have a situation like this:

>> At some point t_0, it so happens that A and B each send a message (m_a
>> and m_b) to all other participants at approximately the same time [0].
>> At t_0, the internal transcript state of A, B and C is the same.
>>
>> When C receives m_a, the consensus check matches and C updates her
>> internal transcript state to include m_a.
>> Now, when C receives m_b, the consensus check won't match since the
>> internal transcript state of C includes m_a, while the consensus check
>> of m_b doesn't (B was not aware of m_a when m_b was sent and hence it
>> was not included in its consensus check).
>>
> That's OK.  m_b's consensus check doesn't have to include every
> message in C's transcript, it just has to be consistent with C's
> transcript.  Which it is!

how exactly C checks the consistency of m_b's consensus check?  I didn't
get this explanation by Trevor:

> On Thu, Nov 21, 2013 at 3:47 PM, George Kadianakis <desnacked at riseup.net>
wrote:
>> Trevor Perrin <trevp at trevp.net> 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.

Maria



2013/11/26 Trevor Perrin <trevp at trevp.net>

> On Thu, Nov 21, 2013 at 3:47 PM, George Kadianakis <desnacked at riseup.net>
> wrote:
> > Trevor Perrin <trevp at trevp.net> 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
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20131128/23911f41/attachment.html>