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

[Ian Goldberg]

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