First, I like Mike's idea in principle. I still see one interesting problem with this (and have no idea how to solve it): The widespread use case of zero-footprint clients, aka webmail: if you have no client / your client is a browser window for webmail, you have to upload your private key to the server (and must store it there). I.e. you would upload your private key to Google and other mail providers. And a part of PRISM was/is to deploy direct access points on these servers in the first place. With the access to all webmail servers and through this to all private keys there, PRISM would at the same time also retain full access to emails received on full-clients. So while this might help us against spam, we might in the end not be much better off against pervasive state-driven surveillance. Or am I missing something?
Best regards, Tobias Re: [perpass] A proposal for developing PRISM-Proof email (default deny) > That is handled by the underlying program you are using to encrypt > your mail, and so has nothng to do with this proposal directly - it's > implementation dependent. Out of scope. I agree that this problem is out of scope, but it is very important nonetheless. Every time someone hits upon a bright idea to make encrypted communication easier to use they run up against the problem of improving key management. [RS> ] +1 Thank you for pointing that out. It's the one of the core problems usabiligy and implementation. "We have met the enemy and it is us." These schemes, however, only work if the user has access everywhere to their list of trusted keys. Essentially, the authenticity problem gets transformed into an availability problem, and the availability problem is perhaps even harder. Three different free software projects try to securely tackle the availability problem and could form the basis for an agnostic protocol for portable and secure data sync: (1) Firefox Sync https://www.mozilla.org/en-US/mobile/sync/ (2) SpiderOak's Crypton https://crypton.io/ (3) LEAP's Soledad https://leap.se/en/soledad All of these are overkill for the narrow problem of key management. Instead, they try to tackle the general question of secure data synchronization and backup. I think this is probably the proper approach. Our hope with the next version of Soledad is to add federation, so that two or more users on different providers could share a synchronized, searchable, client encrypted database. This could be useful for all kinds of things. -elijah _______________________________________________ perpass mailing list perpass at ietf.org https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
