Comment by graue | Hacker News Reader

Comment by graue | Hacker News Reader

> we are creating a client-side, in-browser encryption system where a user can upload their already encrypted content to our storage system and be 100% confident that their data can never be decrypted by anyone but them.

This concept may sound clever at first but gives you as the user no additional confidence compared to encrypting data on the server side upon arrival. Either way, you're trusting the host.

The threat model for server-side encryption is essentially:

1) the host has an unethical employee who wants to read your content.

2) the host's servers are insecure and get compromised.

3) someone successfully MITMs your connection to the host (possibly due to the SSL problems being discussed here).

4) the government compels the host to provide your data (i.e. what happened with Lavabit).

The threat model for browser-based client-side encryption is the same! In any of these cases, the attacker (or the host, in case of #1 or #4) simply sends JavaScript encryption code to your browser with a backdoor in it.

Cryptocat originally worked the same way: all chats were encrypted on the client side, but with JS code sent from the server, in which a backdoor could be inserted at any time. After much criticism, this is why Cryptocat is now a browser add-on, with discrete releases made available from a central source (Chrome Store/Mozilla addons site), which can be audited.

One of cryptic's features is that the front-end is completely open-source. You can see the source for the current prototype here:

https://github.com/cryptic-io/web

We'll be releasing tools, like a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.

And since the whole frontend is open-source and is only html/js/css, you can host it on your own box if necessary.

To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.

Cryptocat was and is open source too:

https://github.com/cryptocat/cryptocat

That doesn't solve the problem. No one is going to manually view source and compare it every time they use the damn thing.

> To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.

At rest. Yes, at rest it's fine, like I said, but if someone logs in while the server is compromised, it would be trivial to decrypt anything they post or access during that session. Same as Lavabit.

> We'll be releasing [..] a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.

So it'll download two copies of the code, one from your servers and one from GitHub, and check that they match? Doesn't seem to me that that buys you much. And unless it's mandatory, you'll be leaving the users that don't install the extension unprotected.

See here for a long list of other reasons in-browser crypto is problematic: http://www.matasano.com/articles/javascript-cryptography/

When you create an account with cryptic.io, a private key is generated in browser and encrypted with the hash of your password. This encrypted private key is what we keep server-side. All files you upload, and all of your user-data, is encrypted using that private key. In short, all encrypting/decrypting of ANY sort happens inside your browser. So someone logging onto the server and viewing data as it is uploaded is still seeing encrypted data. Short of compromising a user's computer there is no way for them to see it. Our encryption scheme is nothing like the scheme that lavabit used.

The extension won't be able to mitigate an attack, but it will be able to alert you to one, which for someone who had the initiative to install it (which we will be heavily encouraging users to do) would be enough to inform them that something is amiss. And if something is amiss they can host the front-end themselves and use a local copy of the html/js/css so they can be sure they're getting a good copy of the site (something we will also be making easy to do).

What happens if a user changes client machines?

You seem to suggest storing their hashed password in the browser, but if they change machines they won't have that hashed password around. How will you go from plaintext password to hashed password without having the salt used with PBKDF2?

You say user passwords are never sent over the wire (not even the hash)[1], but then say users have an object containing their hashed password (is the documentation here out of date?)

[1] - https://github.com/cryptic-io/web

I have thought about a similar service but was dissuaded by various sources warning against the idea of using javascript with cryptography, e.g. http://www.matasano.com/articles/javascript-cryptography/. That's not to say a reasonable solution cannot be found, but there are a good number of issues that need to be addressed. The one that seems crippling to me is that the strength of javascript crypto libraries is questionable at best - nevermind the various other javscript attack vectors. A browser plugin could address some issues, but then that limits users to browsers with the plugin installed. Might as well have a native application where the quality of the cryptographic algorithms are more thoroughly tested at that point. Still, I like the idea and wish you the best of luck.

The browser extension is the missing link. That's what makes it impossible for malicious code in a frontend's source code to go unnoticed.

I wish you had an example of a custom application that uses your storage, so people can see how easy/hard it is to use and customize the frontend for their own applications. How would the browser plugin properly attest the frontend code hasn't been modified if an application dynamically generates custom frontend code per user?

Reply on news.ycombinator.com