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

[Ian Goldberg]

On Sun, Aug 26, 2012 at 09:04:35AM -0700, Howard Chu wrote:
> 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.

I don't see how that would work in the libotr setting.  libotr needs to
be able to get at that private key for a little while, so however it's
stored, there must be a way to derive the key if a DHKEY message
arrives.  If your computer is compromised, the attacker could get at the
private key in the same way.

Even in the setting you state, the security relies on the attacker not
knowing how the wrapper key was computed.  Otherwise, he could just
simulate the calling of the library for a "legitimate" decryption, and
compute the key himself that way.  Actually, nowadays, he could just sit
on another core, watching an actual legitimate decryption happen, and
just yoink the key out of the other thread's memory at the right time.

   - Ian