I've read previous discussions on the faults of browser crypto but haven't come away satisfied. Can anyone suggest problems with the following?<p>A security conscious web developer needs to share credentials with a client. The client isn't adept enough to install a crypto tool. They also need something asynchronous like email - a phone call every time is too intrusive. Existing options include:
1. Email.
2. A third party service with SSL w/ PFS + server side encryption as an intermediary. A malicious service can keep a copy without detection.<p>With in-browser crypto:
- Dev asks client to go to http://sendpasswords.com/.
- Client hits the link. Browser generates a PGP keypair, stores the private key in localStorage and sends the public key to the server. The client is shown a link to send back to the developer.
- Developer visits link and enters a message which is encrypted with the client's public key in browser.
- Client returns to site. Encrypted message is downloaded and decrypted with key from localStorage.<p>This should be at least as good as either existing option. A few additional security assumptions:
- Users know to only access the site via an HTTPS URL or HSTS settings are preloaded in their browsers.
- The HTML + JS is simple, unobsfuscated, static and served in one request; subsequent data from AJAX calls is never executed or loaded as HTML.
- Only browsers providing a CSRNG are supported.
- The HTML + JS is open source and audited by a third party.<p>The host would have a hard time capturing cleartext without detection. They could target specific users, but third parties could periodically load the app and verify the checksums to detect any code change that wasn't narrowly targeted.<p>So long as the audited code couldn't encrypt the message for more than one public key, any interception would be detected when the recipient didn't get the message.<p>Thoughts?
What's the point of this? The server that feeds the Javascript that generates the PGP keys and any server that feeds the Javascript code that performs PGP operations can read arbitrary messages. Why bother with the rubber chicken crypto? Just have users send you plaintext messages over SSL and be honest about it.
First, have you read <a href="http://www.matasano.com/articles/javascript-cryptography/" rel="nofollow">http://www.matasano.com/articles/javascript-cryptography/</a>?