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/ _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
