[OTR-dev] Last-minute change to libotr 4 API

[Arlo Breault]

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 at lists.cypherpunks.ca (mailto:OTR-dev at lists.cypherpunks.ca)
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20120825/fe9ec5dd/attachment.html>