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