<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 12, 2014 at 1:42 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hey guys, I am doing work on partially-ordered transcripts. This was inspired by Old Blue[0], discussions with George Kadianakis and Trevor Perrin, as well as background knowledge on git, and immutable content-addressing schemes as seen in Freenet and Tahoe-LAFS.<br>

<br>
For everyone's interest, here is what I have so far, followed by a statement of some issues that (AFAICS) have not been discussed before, and directions for solving them.<br></blockquote><div><br></div><div><div>Hey Ximin,</div>
<div><br></div><div>We may need a more gentle introduction to this, and pseudocode - not everyone here saw the discussions on OTR-dev, and I think you've worked out new details I don't fully understand.</div><div>
<br></div><div>My take:  You're considering problems that arise when trying to achieve "transcript consistency" for a multiparty conversation.</div><div><br></div><div>The general approach you're considering is for parties to piggyback hash values on the messages they send, referring to the messages they've previously sent and received.  The goal is to protect the context of your message, so that if you send a message saying "yes", an attacker can't perform replay/reorder/deletion to change what it appears you're responding to.</div>
<div><br></div><div>You're raising a couple questions about what happens when users join / leave the conversation.</div><div><br></div><div>You point out that piggybacked hashes sent to new users might leak information about messages before the new users joined.</div>
<div><br></div><div>I'm not sure that's a big deal.  But at least in a "pairwise" situation where each message is separately encrypted to each recipient (instead of using a group key and broadcast medium), wouldn't it be easy to omit old hashes to a new member?</div>
<div><br></div><div>I think you were also concerned about whether users joining/leaving the conversation could get things out of sync?  It seems you've resolved that concern, but I admit I didn't quite follow.</div>
<div><br></div><div><br></div><div>Trevor</div></div><div><br></div></div></div></div>