Now the question is -- why doesn't Google do this with Gmail?
Because it would be deeply irresponsible for them to do that.
Scramble.io: secure email for everyone
31–40 of 142 posts
Re: Scramble.io: secure email for everyone
#32Earlier quoted context omitted.
What else does it look at? I don't see what else would affect it besides things that you could also verify in theory.
Why don't you start building out the answer to that question yourself?
Your comment makes absolute sense if the extension is attempting to validate asset files after they'v been loaded. But the extension can be coded to only load vetted code. So I'm not sure what you're talking about. Please enlighten us.
Re: Scramble.io: secure email for everyone
#33It's nice to see so many projects attempting to solve this problem. I have a question specific to the documentation on the main page:
Private keys are stored on the server in encrypted form. The key derivation function used is as follows:
K = scrypt(Passphrase, Username)
What I'd like is clarification of the Zero Knowledge section that the keypair is decrypted client-side only and the passphrase is never transferred to the server for any reason. This is important because a state actor or other person with sufficient influence--such as a big wrench--could intercept this via code installation on whatever servers perform this work.
There's still the issue of JS being modified by the same evil actor (which you mention), and I'm not sure if signing with a browser extension is much insurance (that's just replacing code that can be modified in transit/on update with other code that can be modified in transit/on update), but with so much attention being paid to this problem as of late, an adequate solution will be discovered (if it doesn't exist already).
Re: Scramble.io: secure email for everyone
#34nice. secure end-to-end encryption with a good browser-based UI is kind of a holy grail.
They say it's open source, but I can't find links to the source anywhere. Anyone?
Re: Scramble.io: secure email for everyone
#35Earlier quoted context omitted.
I'm not a programmer. Why can't you just digest or hash the JS?
Just curious : what does a non-programmer come to HN for? Everything seems fairly programming centric to me here...
Non-programmer here. I've gotten great advice on work and links to great resources that have helped me change the way I work. It's not an overstatement to say that great writers like patio11 and Zach Holman have thoroughly changed how I see work, collaboration, and how it should interface with my private life. I don't run a SaaS app (yet) and I certainly don't make open-source contributions, but the principles of their posts can apply to a lot of fields that aren't purely technical. In the last year and a half since I started regularly reading I brought a lot of great ideas to my previous employer and then changed my career for the better.
tldr: Everything I've read here has given me immense clarity in how I personally view life and work, and I'm happier for it.
Re: Scramble.io: secure email for everyone
#36Earlier quoted context omitted.
I'm not a programmer. Why can't you just digest or hash the JS?
Just curious : what does a non-programmer come to HN for? Everything seems fairly programming centric to me here...
To broaden their horizons? Because they're interested in technology even if they don't define themselves as a programmer?
Just curious: why would a person comment not to add value, but to ask a semi-snarky rhetorical question?
Re: Scramble.io: secure email for everyone
#37Another week, another Javascript cryptography project. See: https://news.ycombinator.com/item?id=6637915 https://news.ycombinator.com/item?id=6420739 https://news.ycombinator.com/item?id=6353137 https://news.ycombinator.com/item?id=6317685 (That's just the last few weeks). We are also developing a browser extension which will verify the Javascript loaded from the server. (Until then, an attacker who gained control of…
You can have a signing committee vet the asset files and publish the signatures, which the browser extension looks for. It allows an upgrade path without having to go through the browser app store. For example, browser extensions installed using the Chrome app store updates automatically, which implies trust in Google. The browser extension would only load vetted assets onto the DOM. In other words, you visit the sit…
Or just have the signing committee publish signed JS code. There's no real difference between that and publishing a signed hash. Unfortunately other hostile extensions are still free to mess with the DOM, so it's all a bit pointless.
Re: Scramble.io: secure email for everyone
#38Another week, another Javascript cryptography project. See: https://news.ycombinator.com/item?id=6637915 https://news.ycombinator.com/item?id=6420739 https://news.ycombinator.com/item?id=6353137 https://news.ycombinator.com/item?id=6317685 (That's just the last few weeks). We are also developing a browser extension which will verify the Javascript loaded from the server. (Until then, an attacker who gained control of…
Just to clarify, as I've seen many of your responses to posts on this subject, you're advocating against use of javascript encryption in client-side applications served through the browser.
If the encryption library were running on a server using node.js or packaged into a mobile app using a framework like Phonegap it doesn't matter that the implementation is in javascript, does it?
Re: Scramble.io: secure email for everyone
#39Earlier quoted context omitted.
Why don't you start building out the answer to that question yourself?
Your comment makes absolute sense if the extension is attempting to validate asset files after they'v been loaded. But the extension can be coded to only load vetted code. So I'm not sure what you're talking about. Please enlighten us.
If the entire system lives in a browser extension, you're doing what I said in the comment at the top of this thread --- and why would you bother "loading" anything from the server at all? If you know the hash, you know what the file is supposed to be.
Otherwise, almost every rendezvous you have with the server is an opportunity for methods to be rebound and your cryptosystem to be subverted. If you don't see how, it's a good exercise to investigate.
Re: Scramble.io: secure email for everyone
#40Another week, another Javascript cryptography project. See: https://news.ycombinator.com/item?id=6637915 https://news.ycombinator.com/item?id=6420739 https://news.ycombinator.com/item?id=6353137 https://news.ycombinator.com/item?id=6317685 (That's just the last few weeks). We are also developing a browser extension which will verify the Javascript loaded from the server. (Until then, an attacker who gained control of…
Yeah, I read your Matasano post, "Javascript crypto considered harmful", and I agree-- Javascript crypto is hard!
But it's not impossible.
The reason I chose that route is because I want to make it as easy as possible for users to try out and adopt. Just testing it out? No installation required.
I think that security is at least equal parts a technical problem and an adoption problem. The status quo is that nearly all email is searchable plaintext as far as strong adversaries are concernd. I want to fix that.
> If you're going to build a browser extension, put the crypto code in the extension.
The hard part is running known, trusted JS. Simply packaging the same HTML/CSS/JS as a browser extension was certainly my first impulse! The issue then is that you can never ship an update--users must proactively upgrade--unless you have an auto update mechanism for the extension (eg, Play Store) at which point you're again at the mercy of the server, no better than a web app.
Once you get trusted code running on the client, you can bootstrap. The system I envision is as follows: you, a power user, download the browser extension. You verify the signatures. There are multiple signatures--not just my own--so that no one party can release a tampered client. A set of independent, trusted organizations around the world must sign each release. Let's call them the Signature Committee.
The browser extension simply contains the public keys of each member of the signature committee, and a small bootstrap loader. When you run the browser extension, it gets the latest assets from the server, along with a signature file---and it checks that enough members of the signature committee have signed them.
You know have trusted code, but the developer can still--with the consent of the signature committee--push out updates.
I think that the Signature Committee concept has very cool properties. Currently, even security-critical client applications--for example, the Tor Browser Bundle--are usually only signed by a single organization--in that case, the Tor Foundation. Given that governments have shown themselves willing to coerce organizations to conspire against their users, and to do so in secret, we need something better. I envision a future where Scramble keeps improving continuously, but no one organization--not even any one country--can unilaterally ship an update.
Thanks for your feedback!