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

[Trevor Perrin]

On Sun, Nov 10, 2013 at 1:32 PM, George Kadianakis <desnacked at riseup.net> wrote:
> Hello again Matthew (and otr-dev),
>
> I was recently thinking of ways to make sure that all participants of
> a multiparty chat see the same transcript at all times. It seems like
> a very important security property.
>
> Papers like mpOTR (and the recent "Improved Group Off-the-Record
> Messaging" paper by Liu et al. [0]) are "solving" the problem simply
> by sending out a hash of all previous sent and received messages. This
> seems like a crude solution that does not even allow you to detect
> out-of-order messages (which can make a big difference when human
> beings communicate with each other).


Hi George,

I'm wondering if sending a "hash of all previous sent and received
messages" is really that crude an approach.

Suppose message flow from any user X to user Y is ordered, reliable,
and all messages arrive within some reasonable time interval, eg 1
minute.  Then piggybacking a "consensus check" on each message in a
multiparty chat seems good to me.  For example:

"In this chat, prior to sending this message at time 20130809T0418Z,
I've received 7 messages from Bob, 6 from Charlie, and this is my 9th.
 Here is a hash calculated over all these messages, in sorted order
(first my 1-9, then Bob's 1-7, then Charlie's 1-6)."

If any party receives a message with
 a) an incorrect hash, or
 b) whose value is inconsistent with previously-received hashes, or
 c) where the sender's view is excessively out-of-date, or
 d) where the receiver's view is excessively out-of-date,

then this is a security error, and the chat is shut down.


> I also read your "OldBlue: Causal Broadcast in A Mutually Suspicious
> Environment" paper [1], and it seems like it would fit nicely in the
> multiparty chat scenario.

Seems like OldBlue is trying to cope with arbitrarily re-ordered and
dropped messages via acks, retransmission, etc.

Is that necessary, for chat?  It would seem easier to detect such
violations of chat integrity as security errors, and not try to
recover from them.


Trevor