[messaging] Asynchronous Ratcheting Tree

[Jonathan Millican]

Hi, I was one of the Collaborators on this paper. Thanks for reading it!

You're absolutely right that we don't define a way to merge operations into
a linear order. We actually deliberately left this out of scope: largely to
keep things simpler for the initial proofs of the structure, and partly
because there are potentially a number of ways to do this which may have
different trade-offs in different situations. For example, a protocol could
require a central server to rejects messages which are not premised on the
correct root node; or perhaps you could require a strict global ordering on
messages where the "winner" in an instance of conflicting updates is simply
whichever update came first.

Regarding merge operations, conflicting updates to a tree shouldn't be
commutative in the general case, but I think there may be circumstances
where limited merges could occur:

Take the following tree:

        DH(DH(A, B), DH(C, D))
       /                      \
   DH(A, B)                DH(C, D)
  /        \              /        \
 A          B            C          D

If A and B were to send simultaneous updates, ( [A', DH(A', B)] and [B',
DH(A, B')] ), then C and D are unable to merge them at all; as this would
require computing DH(A', B') without access to either private key.

However, if A and C were to send simultaneous updates ( [A', DH(A',
B)] and [C',
DH(C', D)] ), then everybody is able to merge them. The general intuition
here is that you should be able to merge a single update to each branch of
your copath; but if two updates come off the same branch then merging them
would require you to solve the Diffie-Hellman problem.

Assuming I got the above correct (it's late so I may not be thinking
straight), I suspect that this may mean that a protocol could be built
whereby between 0 and log(n) conflicting updates can be merged at a time,
depending on who the sender is. Even if we don't have a situation like the
above where absolutely everybody in the tree is able to compute the entire
merged tree; so long as the person sending the next message is able to,
then they can recompute all of the relevant copaths and send them to
everybody else along with their own update.

Of course, this suggestion involves its own complexity and likely
performance/network trade-offs; so I have no idea if it would actually be a
good one in practice. Potentially though, it might be one model for limited
merge support. I also haven't really considered whether this would
compromise any security properties, which would be important to look into!

Hope that makes some sense,
Jon


On 9 January 2018 at 12:34, Ximin Luo <infinity0 at pwned.gg> wrote:

> I was just forwarded this: https://eprint.iacr.org/2017/666
>
> On Ends-to-Ends Encryption: Asynchronous Group Messaging with Strong
> Security Guarantees, by Katriel Cohn-Gordon and Cas Cremers and Luke
> Garratt and Jon Millican and Kevin Milner
>
> It looks very nice. However, on a quick glance through the paper, it
> doesn't define a way to merge operations performed on the DH group tree.
> That seems to constrain the group chat to rely on some external mechanism
> to ensure that operations on the ratchet are performed (by everyone) in a
> linear order - i.e. it would still have to operate synchronously.
>
> (This constraint is fulfilled trivially in a two-party ratchet because
> each sender always sends in a linear order, wrt the other recipient.)
>
> I wonder if it's possible to define a merge operation on the DH group
> tree, so that e.g. Bob and Carol can advance the ratchet independently of
> each other (e.g. to B and C, each from state O) such that when Alice
> receives B and C, she can construct the merged ratchet state X that
> combines both changes (O to A) and (O to B)?
>
> Alternatively, an explicit merge algorithm is not necessary if it can be
> proved that applying O->A and O->B on top of O is commutative.
>
> X
>
> --
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180109/b1f825e6/attachment.html>