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