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

[Howard Chu]

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

Since there are no other uses for this yet, it might be better to make this a
oneshot function. And change the signature of otrl_poll() to also return a
polltime. If it returns 0, then no further polling is desired, otherwise the
return value is the interval till the next desired poll. Setting up a
permanent alarm/timer in the app seems a bit unfriendly, particularly if it is
rarely needed.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/