Re Sam's proposal, essentially. I thought it might be worthwhile to be more explicit about my models for device compromise:
Ephemeral compromise: The adversary can read the contents of some (possibly limited) set of memory locations, including the location where the key is stored. (E.g., some browser security bugs, Heartbleed.) Temporary compromise: t=day 0. Adversary uses a vulnerability to establish persistent presence (formerly hard in-browser, but now possible via, e.g., ServiceWorkers...) t=... malicious software uses other vulnerabilities to read keys t=n days. The bug is fixed and platform-level protection mechanisms eliminate the malicious software. Permanent compromise: The adversary replaces part of the platform's trusted computing base (be it hardware or software) with code it controls. Keeping private keys unencrypted in memory for only a short period of time is an okay way to protect against ephemeral compromise. It does nothing to protect against temporary compromise. (And nothing we do can protect against permanent compromise; for code running in a browser, that's the browser's responsibility.) - dlg _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
