On Sun, Aug 26, 2012 at 09:40:35AM -0700, Howard Chu wrote: > > 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.
No, sorry if I was unclear. The point of this proposal is that, after some reasonable amount of time (one minute, say), the private key in the COMMIT message is *no longer needed*, and can be completely wiped from memory. If the machine is compromised after that point, past messages are indeed safe, no matter how clever the attacker. If an attacker compromises a user's machine at time T, the goal is to minimize the size of the time interval D such that messages sent/received before time T-D are secure from the attacker, while messages sent/received after time T-D may still be available to the attacker. The way the current master branch has it, there are a handful of messages (the first ones of each OTR session) for which D might be needlessly large. - Ian _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
