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

[Howard Chu]

Ian Goldberg wrote:
> 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.

Unfortunately this is always true, even for the timed erase that you proposed.
When a machine is compromised, every scheme you devise boils down to security
by obscurity, because all of the required inputs are present *somewhere*. The
best you can hope for is to make it inconvenient for an attacker.

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