<div style="font-family: Helvetica; font-size: 13px; ">If it's only the first messages, you can start the conversation with heartbeat packets so that compromising them is meaningless.<br></div>
<div></div>
<p style="color: #A0A0A8;">On Saturday, 25 August, 2012 at 7:50 PM, Ian Goldberg wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>I really wish there was another way to do this. Suggestions are</div><div>extremely welcome.</div><div><br></div><div>While tracking down the problems I mentioned yesterday, I came across</div><div>this issue:</div><div><br></div><div>- Alice sends an OTR Query message to Bob</div><div><br></div><div>- Bob sends a COMMIT message to Alice</div><div><br></div><div>- Alice repies with a DHKEY message</div><div><br></div><div>* At this point, the 3.x code would forget about the commit message, but</div><div> in 4.x, in order to allow for the case where Alice is logged in more</div><div> than once, Bob needs to hold on to the commit message, and in</div><div> particular, to the private key that generated it, so that he can set</div><div> up an OTR session with each of Alice's logins. [Recall that the</div><div> major change in 4.0 over 3.x is that it addresses the "Alice is logged</div><div> in more than once" problem.]</div><div><br></div><div>So even after Alice and Bob have established an OTR session and are</div><div>happily chatting, the current 4.x (master branch) code still has a copy</div><div>of the private key used to generate Bob's COMMIT message stashed away.</div><div>If Bob's computer's memory is compromised after that point, this private</div><div>key may be able to be used to decrypt the first messages of the</div><div>conversation. This is undesirable.</div><div><br></div><div>A plausible thing to do is, after a "reasonable" amount of time, Bob</div><div>should erase the private key. If one of Alice's login instances is</div><div>extremely laggy, and that instance sends its DHKEY message after that</div><div>time, it will be ignored as spurious.</div><div><br></div><div>The problem is, suppose Alice and Bob exchange just a few messages</div><div>quickly (before the "reasonable" timeout period), and then stop typing.</div><div>There's no reason that *any* libotr function will be called for an</div><div>arbitrarily long period of time, and so no code could run to erase that</div><div>no-longer-needed private key.</div><div><br></div><div>So here's the proposed change. Again, alternate suggestions (the sooner</div><div>the better) are extremely welcome.</div><div><br></div><div> There will be a new function</div><div> </div><div> polltime = otrl_polltime(userstate);</div><div> </div><div> you must call right after creating your userstate that will return a</div><div> number of seconds.</div><div> </div><div> The calling application must then call (in the same thread as the</div><div> rest of libotr, to be sure)</div><div> </div><div> otrl_poll(userstate, uiops, uiopdata);</div><div> </div><div> every polltime seconds (or thereabouts; exactness is not important).</div><div> The otrl_poll function will do any periodic cleanups necessary for</div><div> forward secrecy purposes (and, I suppose, any other operations that</div><div> should be done periodically, but none is needed at the moment).</div><div><br></div><div>Comments, please?</div><div><br></div><div>Thanks,</div><div><br></div><div> - Ian</div><div>_______________________________________________</div><div>OTR-dev mailing list</div><div><a href="mailto:OTR-dev@lists.cypherpunks.ca">OTR-dev@lists.cypherpunks.ca</a></div><div><a href="http://lists.cypherpunks.ca/mailman/listinfo/otr-dev">http://lists.cypherpunks.ca/mailman/listinfo/otr-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>