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

What about just keeping this private key encrypted with a 2nd key? Once upon a
time I used this approach to solve a similar issue (a Windows Kerberos 5
client, back in 1995. It was widely used in the Eudora email client, among
other places) - the wrapper key was derived from the stack contents upon entry
to the keystore; it was never stored anywhere. It was generated on the fly,
and the library would only successfully unlock the keystore if the exact same
sequence of functions was used to call into the library every time.

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