<div dir="ltr"><div><div><div>Hi, I was one of the Collaborators on this paper. Thanks for reading it!<br><br></div>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.<br><br></div>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:</div><div><br></div><div>Take the following tree:</div><div><br></div><div><div><font face="monospace,monospace"> DH(DH(A, B), DH(C, D))</font></div><div><font face="monospace,monospace"> / \</font></div><div><font face="monospace,monospace"> DH(A, B) DH(C, D)<br></font></div><div><font face="monospace,monospace"> / \ / \<br></font></div><div><font face="monospace,monospace"> A B C D</font></div><div><br></div><div>If A and B were to send simultaneous updates, ( <span style="font-family:monospace,monospace">[A', DH(A', B)]</span> and <span style="font-family:monospace,monospace">[B', DH(A, B')]</span> ), 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.</div><div><br></div><div>However, if A and C were to send simultaneous updates ( <span style="font-family:monospace,monospace">[A', DH(A', B)]</span> and <span style="font-family:monospace,monospace">[C', DH(C', D)]</span> ), 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.</div><div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>Hope that makes some sense,</div><div>Jon<br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 January 2018 at 12:34, Ximin Luo <span dir="ltr"><<a href="mailto:infinity0@pwned.gg" target="_blank">infinity0@pwned.gg</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was just forwarded this: <a href="https://eprint.iacr.org/2017/666" rel="noreferrer" target="_blank">https://eprint.iacr.org/2017/<wbr>666</a><br>
<br>
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<br>
<br>
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.<br>
<br>
(This constraint is fulfilled trivially in a two-party ratchet because each sender always sends in a linear order, wrt the other recipient.)<br>
<br>
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)?<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
X<br>
<br>
--<br>
GPG: ed25519/56034877E1F87C35<br>
GPG: rsa4096/1318EFAC5FBBDBCE<br>
<a href="https://github.com/infinity0/pubkeys.git" rel="noreferrer" target="_blank">https://github.com/infinity0/<wbr>pubkeys.git</a><br>
______________________________<wbr>_________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/<wbr>mailman/listinfo/messaging</a><br>
</font></span></blockquote></div><br></div>