<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>