

Ask HN: Is sending passwords a good use of JS crypto? - mballantyne

I&#x27;ve read previous discussions on the faults of browser crypto but haven&#x27;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&#x27;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&#x2F; 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:&#x2F;&#x2F;sendpasswords.com&#x2F;.
- 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&#x27;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&#x27;t narrowly targeted.<p>So long as the audited code couldn&#x27;t encrypt the message for more than one public key, any interception would be detected when the recipient didn&#x27;t get the message.<p>Thoughts?
======
tptacek
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.

~~~
mballantyne
The server can only read arbitrary messages if it changes the runtime that it
serves. If it were to serve the wrong runtime to more than a narrowly targeted
set of users, it could be detected (by, say, a third party running an
automated script to check for changes in the served files).

This also means that targets of interest would have to be identified at time
of their use of the service (so as to avoid detection as above) by something
other than the content they're sending, whereas a malicious service receiving
the plaintext could search through all received plaintext for interesting
content without detection.

It would make an attacker expend effort and risk per-target. In a world of
mass data collection, that seems valuable for those who aren't targets of
particular interest but want to avoid the dragnet.

~~~
tptacek
The DOJ didn't want everyone's mail at Lavabit. It wanted Snowden's mail. The
DOJ will feed malicious JS to its targets, and innocuous JS to everyone else.

~~~
mballantyne
Yep. They would. Snowden should be using PGP on an air-gapped machine inside a
faraday cage, right? This isn't for him. This is for the rest of us that are
at most mildly interesting but don't want to give in to the surveillance
state, or just want to send a password without blindly and completely trusting
at least one third party. Isn't such a mid-security but easy to use solution
valuable? The more PGP-armored messages there are (even if they could be
broken with effort), the less suspicious any such use of crypto can be
considered.

~~~
tptacek
There is virtually no correlation between the people who need to have their
secrets protected from hostile governments and the people who are savvy enough
not to use applications that make security promises they can't keep.

~~~
mballantyne
The security promise is simply "this is better than plaintext email, which is
what you'd use otherwise."

I'd rather have as much of my communication as possible protected from mass
collection by my own government regardless of it's sensitivity.

Edit: Misunderstood your phrasing a little. Yes, ideally we would provide non-
savvy users with trivially easy to use encryption strong enough to defeat
hostile governments. I haven't seen it yet. I make no pretense of
overpromising - I'd certainly expect a service such as I'm describing to
prominently note that it shouldn't be used for material above a certain
sensitivity and link to info on better options.

------
wglb
First, have you read [http://www.matasano.com/articles/javascript-
cryptography/](http://www.matasano.com/articles/javascript-cryptography/)?

~~~
mballantyne
I hadn't yet seen that particular article but I'm very familiar with those
arguments. Thanks for the link!

I agree with them that building a crypto library in JS that can be trusted
regardless of the security properties of the web application is impossible
(content-controlled code, runtime malleability).

However, I don't think those points mean that building an application that _as
a whole_ has good security properties and uses JS crypto is impossible. If the
entire application code is delivered on first load and code is never
dynamically loaded, one should be able to audit and trust that complete
application. That'd mean no ads, no google analytics, no CDNs, etc.

The next bit is reliable delivery. SSL is definitely needed. Because static
code is all delivered on first load, an interested third party could download
it at any time and see that it matches the audited code. The host would be
caught if it attempted any attack that wasn't narrowly targeted.

And that's why it's better than just SSL. If the host receives the plaintext,
there's zero chance of catching them.

Their points about graceful degradation and CSPRNGs are irrelevant; I'm only
interested in targeting modern browsers with window.crypto.getRandomValues.

~~~
tptacek
You can't just audit the code. You have to audit the whole runtime, every time
the app touches the web server. It's not a tractable problem.

