Scramble.io: secure email for everyone
dcposch.github.io
dcposch.github.io
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 a server could tamper with the JS to steal a user's credentials the next time they log in.)
Baffling. If you're going to build a browser extension, put the crypto code in the extension. This still isn't a great solution, but it's better than trying to "verify the Javascript code". How exactly do you plan to do that? Surely you realize you can't just digest the JS asset files.
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.
Just curious: why would a person comment not to add value, but to ask a semi-snarky rhetorical question?
Besides, "Programming" is a large spectrum; I know jack-all about javascript but am comfortable building CRUD apps in C# and am in the intended audience of "don't build your own crypto because you're an idiot" blog posts. I consider myself a programmer (even though I have a lot to learn) and had the same question in my head as DigitalJack.
I'm technically minded though--chip designer. Software is a hobby for me. I guess I more meant that I'm not a JavaScript programmer and don't know the subtleties of that ecosystem.
The browser extension would only load vetted assets onto the DOM. In other words, you visit the site by opening a new tab and clicking on the extension. It then loads assets and checks that all the assets are signed by a trusted list of code-vetting signers. If all the signatures look good, then it loads the assets onto the DOM. This is no less secure than having all the client code in the extension.
I don't see what else would affect it besides things that you could also verify in theory.
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.
It would work if the plugin can inspect all browser requests attempt and verify every single asset before it's loaded into the browser.
How do you know which public key belongs to the address? Key servers? Web-of-trust? Look it up on their homepage?
Scramble has an address -> pubkey resolution system which balances security with usability.
At least with Scramble you can create a secure USB stick to boot from with all of that preconfigured. Any solution that uses bare GPG still has severe usability problems.
I salute what you are trying to do, but you have to understand that the Js browser method, as it stands today, is a dead end.
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?
[1]https://hellais.wordpress.com/2011/12/27/how-to-improve-java...
[1] http://www.contextis.com/files/Browser_Timing_Attacks.pdf
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!
Your reason for using browser Javascript for crypto --- here, Recurity's JS PGP implementation --- is the same as every other JS crypto project's reason: doing everything in the browser makes it easier for users to adopt your project. You are not the first person to point this out and you won't be the last.
The problem is, you acknowledge one side of this design ("it's super easy for users") and ignore the other ("it's fatal to security").
Here, you even acknowledge that there was a simple mechanism available to you that might have marginally improved security (packaging the whole application as a Chrome extension). But that made your life too hard! So you abandoned that idea and just made all the crypto downloadable from the server on HTML pages!
I'll respectfully disagree.
> But that made your life too hard! So you abandoned that idea
We haven't abandoned the Chrome extension idea at all. We just think there's a better approach than "packaging the whole application as a Chrome extension". Doesn't sound like you read my reply.
You're essentially asking to be the next Lavabit. You've added a verification component that probably won't work even for the verifiers. But that doesn't even matter, because the majority of your users won't even be doing that verification.
The FBI decides they'd like to read that conversation. They issue a court order requiring you to hand over your TLS private key, and use it to MITM your users to feed them corrupted JS code that discloses PGP private keys.
The small minority of users "detect" this change. But not quickly enough: the whistleblower has already logged in to check their mail, and has now disclosed their private key to the FBI.
What now? What's the feature you're going to build to keep that from happening?
Not only are you using Javascript crypto to provide this "service" to users, but you're not even forward secure.
But decreasing the amount of dragnet surveillance by some extent sounds like a good thing to me. For example, many people wouldn't like the government to know mundane stuff about them, like having an abortion.This could help.
* BTW haven't moxie written about an asynchronous diffie hellman key exchange ? it could at least give PFS to this , so the private key would be much less useful ?
I find it far more dangerous for someone to think they're secure against government level threats, than to know they're not. And if you're not worried about government level threats, gmail with MFA and pinned chrome certs is likely safer than this project. Of course, this is all just my humble opinion...
If the Scramble.io people ship ALL OF THE PROGRAM LOGIC IN THE EXTENSION, it could be secure. But if any program logic (javascript) they interpret is delivered to the user via HTTPS, it will not be secure.
In general, dragnet security will always be possible as long as you can do statistical analysis over both targets in the network (or the whole network), which the NSA has proven it can do.
My point in the previous comment was that dragnet surveillance wouldn't work at all unless the client's code was compromised, but there isn't a good way for the NSA to compromise ALL OR MOST of the clients' code without it being detected by those users who use the extension. Remember the TorMail episode where malicious javascript was injected in the response? If some users had a Firefox extension that checked to make sure that all the JS code was signed by a committee, then they would have raised the flag and alerted everyone not to use TorMail.
Committee depends on things like number of nodes in the network and integrity of the nodes, not to mention you can still do analysis on who was sending or receiving something at a particular time (which may not be enough to stand up in court, but it's enough for the NSA to know that Mike is talking to Jeff, or whomever).
At the end of the day, the best method currently available for clandestine activity on the internet is one-time anonymous drop boxes, and luck.
1. Browsers, at least the ones that matter, provide window.crypto (with a CSPRNG). This makes generating IV's for CBC "safe," makes generating RSA keys "safe," makes generating random keys "safe." Or am I missing something? Assuming the JS crypto code itself is actually sound, the PRNG seems to be the missing link...or at least, it was.
2. Packaging the entire app as an addon (assets, javascript, views, everything) means the app can be signed and verified. No in-app code updates. If you want an update, download the latest extension. The article assumes that people will do what OP is doing: downloading code and running it dynamically. I agree this is a no-no, even if verifying.
Is there some sort of attack vector I'm missing? I think it's fair to assume the browser is an attack vector, just like hardware is, just like the OS is, or whatever language VM you're running on, etc...but that seems tangential to the process of packaging/signing an entire javascript app and distributing it as an add-on. I also know about the unsafe memory stuff, but this just brings browser encryption down to the level of Python/Ruby/etc. I'm not dismissing this concern, I'm saying that if you're attacking javascript for having this vulnerability, you must also attack any GC language (which you do in the article).
How is in-browser encryption so different from any other java/python/etc app when packaged/signed? I'm not talking about replacing SSL, I'm talking about encrypting data via AES/blowfish in a browser extension with a key generated from a password, and if the data leaves the browser, using SSL on top of that.
What makes it impossible to do this and gain the same level of security as any other language/platform?
When you're just an XSS away from an attacker doing:
function encrypt(plaintext) {
$.post(plaintext, ...);
return plaintext;
}
Sure, you can set up your app to stupidly do evals everywhere, but you can program a bad app in any language.
> XSS isn't the only way either
That's very, very vague. I asked what the attack vectors are. Saying "others" doesn't really work for me.
Another vector to get rogue JS into a user's browser is cache-poisoning, something the article also brings up.
[1] http://media.blackhat.com/bh-us-12/Briefings/Osborn/BH_US_12...
"XSS isn't the only way either." That's about as illuminating as saying "something bad could happen."
No one is saying JavaScript or browser security is perfect, but if you actually know what you're doing, it can be done properly.
The original "JavaScript security is doomed" Matasano article is extremely out of date at this point, and yet people keep referring to it like it's gospel.
As for the chrome extension thing, the project clearly states that it is currently a proof of concept and is missing this crucial part which is currently being built. Somehow you try to turn this into an ad-hominem attack on the developer's supposed laziness.
1. How do you revoke a compromised signature comitee certificate embedded in the browser extension?
2. How can you prevent a hostile browser extension from hijacking the validation process?
1. We could require the signatures to be recent, and if there are any certificates that need to be revoked, we could require that all signers include that information in the data signed. What do you think?
2. If other hostile browser extensions can hijack the validation process, then the only solution is to not have other browser extensions. Paranoid users who need strong security should boot from a fixed image that has a vetted browser with only one browser extension already installed.
Re: 2. Yes, you can't have any other browser extensions. But that is totally unrealistic. It's just a a complete showstopper.
Even a bookmarklet could bypass your cryptosystem!
>> A better approach would be to have the client pull a list of revoked certs along with the JS source/hash.
That's not much better, as the client will have to pull a list from somewhere, and that somewhere could have been compromised to serve a bad list. At least with a window you always need an absolute majority. I'm not liking any of these solutions, so you make a good case for packaging an extension with all of the client code!
>> It's enough for me because I don't use any browser extensions. Maybe it's a showstopper for you because you use other chrome extensions that you don't trust. Here's an idea -- we could offer the client as a standalone application with embedded Chrome. Then you can have your untrusted browser for all your normal browsing purposes, and a separate Scramble app.
I have no idea what you mean about a bookmarklet bypassing the cryptosystem. Are you suggesting that a user clicking on a malicious bookmarklet can thwart security? The user can always thwart his own security.
Yes it is. As I said you'll need a majority-wins system, i.e. the list of revoked certs is signed by a majority of the signature committee members. Using a window is wide open to attack, it has no redeaming features.
> It's enough for me ...
Unfortunately, "it works on my computer" is not going to cut it. I use a few browser extensions, but now those extensions' own update mechanisms can be used to attack your cryptosystem - even a "good" extension could be hijacked this way. That gives me a lot to worry about...
My point with bookmarklets was that many bookmarklets pull down code from an external server and inject it into the local page, so if the user makes use of any booklets as part of their email workflow then those bookmarklet sites now become attack vectors for your cryptosystem. Likewise, browser 0-days are also attack vectors for your cryptosystem which would not be present in say, a stand-alone client. The attack surface area of a browser is huge.
As mentioned in the writeup, there's a beautiful way you can protect even non-power-users. Because the extension downloads and verifies the webapp HTML, CSS and JS every time it runs, the web app is constantly being validated.
As long as you have a critical mass of power users who installed the extension, an adversary cannot tamper with the web application without immediately being noticed.
A strong adversary could still commandeer the server and serve tampered JS to a specific IP without being detected. Users who are specially targeted by such an adversary must either install the extension, use Tor, or both.
My goal is to make Scramble usable by a wide range of people. For a nontechnical user, it's just as easy as using Gmail--and at a minimum, they get the advantage that Scramble servers never store plaintext.
A user with stronger requirements can do more, and can get stronger security guarantees.
When you build and promote a system like this, you are assuming a responsibility on behalf of your users. You should take that responsibility more seriously.
You don't even have that. From what I can tell, you have literally no argument at all; instead, you "agree" with the article while drawing exactly the opposite conclusion that the article draws, then point out again and again how much users don't want to install things, as if that changed the security of this system at all.
Scramble performed encryption on the server, then my argument is false. But the design of Scramble's protocol is such that the security of the application depends only on securing the client code, which I argue can be done, for those who set up their environment correctly.
EDIT: And you seem to be saying that this is actively bad, which I think is just jumping the gun without identifying any actual issues. Having it be only partially secure until you install a browser extension and then having it properly secure most certainly falls into 'good' and not 'bad' or 'great'.
Imagine the following. An Attacker manages to hijack your server. They fingerprint[1] the browsers of each user and only send malicious JS to certain users that dont use your extension. No one will ever know, that they have been compromised.
Why not offer an option to try it out in the browser(with same GUI), and if they want security tell them to install it(and verify)? It would be just a bit harder than installing the extension.
BTW:there's another use case for extension based encryption: As the backbone for private messaging for various sites(which requires integration with the browser) , for example reddit.
private messages in reddit are :
(a)viewable to sniffers due to http usage
(b)can be viewed by reddit staff
(c)can be viewed by dragnet and targeted surveillance
An extension would definetly reduce attack scenarios, and has a good viral marketing vector. In fact implement the right way i could see it being a very reliable way to making something like this popular.
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).
Why go through all the trouble of attempting strong client side crypto, only to store the private key secured only by a passphrase on the server?
If it had just been a technical risk or a financial risk to myself I would have pursued it, but some risks are heavier than others.
I had a damn good name, too, but good job someone else did it so I don't have to! :)
Why would you take that risk and not encrypt in a client using GPG?
* Clear visual distinction between encrypted and unencrypted mail * Keep track of read vs unread mail * Allow users to enter a public key for an external (non-Scramble address) and sent encrypted mail to existing PGP users * Basic search
requirement 1. message integrity and security
1a. use public-key cryptography
- step 1. Person A writes a letter to Person B.
- step 2. Person A encrypts a message using Person B's public key.
- step 3. Person A sends encrypted message to Person B.
- step 4. Person B receives and decrypts the message using Person B's private key.
requirement 2. clandestine recipients
1a. coded messages
- con: coded messages are usually broken after enough messages pass
1b. steganography
- not difficult to detect if messages sent often
1c. dead drops
- pro/con: MITM has to monitor the drop box to determine recipient
1d. peer-to-peer message passing
- can still determine recipient using statistical analysys
You have four nodes in your network: B, C, D, E. B wants to send E a message, but doesn't want anyone who might be observing the whole network to know.
B sends garbage messages all day at random to all active peers on the network, or as close as possible. We'll assume an even distribution of these random messages. When it comes time to send the correct message, it gets delivered just like all the others. This really only works if each message is received by a real peer.
What you get is a constant stream of communication at random, in which case you know 99.9999% of it is junk, and maybe 0.0001% is real. At this point the observer will start drilling down into everything possible to increase the probability of detecting the authentic message. You'll have to prove none of their methods would be able to improve that quality, but an actual cryptographer would be a better person to ask about that.
If you design based on anonymous communication, it's still subject to analysis of network traffic. Even if the messages you're sending are secret, and you have some peers in the middle storing and handing things off, you can still tell who is sending something and who is receiving something and tell with a high probability if the two events are linked.
If you design based on the premise of hiding amongst a bunch of nodes, or wandering randomly through a maze of lots of nodes, you're dependent on lots of nodes and their expected behavior. The number of nodes may diminish, or their routes may be controlled, or their behavior changed, depending on the influence of the observers/controllers of the networks.
I'm of course only speaking about the delivery mechanism. The encryption of the message on either end is the easy part. It's getting it over there secretly that's really hard.
I'm not aware of any application that provides secrecy besides BitMessage. Are there others?
As a user, why would I want to delegate my key management to you? Encrypting the email I want to send to a person with their public key is what gives me a sense of trust that what I am sending is encrypted and only readable to that person.
However--as the example of Tormail and others show us--the server cannot be trusted to serve uncompromised client-side code, even if the organization behind it is well intentioned.
So then why am I trusting you with my PGP keys?
The beauty of it is that Scramble encrypts and signs whenever the recipient is also a Scramble address--automatically. The goal is to protect even users who don't know what a "PGP key" is.
(Don't get me wrong, we're planning improvements for power users as well--for example, we want to make it easy to use Scramble over Tor. But the goal really is "Encrypted email for everyone".)
> So then why am I trusting you with my PGP keys?
No, as explained in the writeup, the server stores your private key encrypted with your passphrase. The server never sees your passphrase, or your private key.
We've used a good key derivation function (scrypt)---this makes it difficult to brute-force the password.
In short: Yes, the server stores things so that you get the Gmail experience, sit down at any computer and it just works. No, the server never sees your plaintext private key.
Thanks for the feedback! If I get a chance, I'll paraphrase your questions and add them to the upcoming FAQ.
The only place a private key belongs to is the users machine (preferably somewhere without internet access).
The logo is a Rubik's cube. That's not a great logo for a cryptographic app because Rubik's cubes are trivially solvable.
I found it really annoying that this service has xkcd style password requirements. My 9-character password with non-alphanumeric characters should be sufficient.
Scramble has not been widely vetted, so don't rely on it to protect you just yet.
The authors put the above line as part of the very first bit of marketing you encounter. Until the JS has full (vetted, industry standard) crypto functions designed to be secure for the each target platform, vetting this kind of crypto is going to be hard. The addition of a cryptographically sound PRNG is a big move in the right direction. That said, I believe the authors got it right with what is currently available: Inform the user in such a way that there is no confusion, open source the code so others can participate in vetting, get some attention to the project so others are motivated to participate in vetting, and continue to improve as problems are discovered. That's really the best you can do, IMHO. In security, the author of a library needs to be correct 100% of the time while an attacker needs to be correct only once.
Crypto code needs to be packaged/signed/verified and cannot load in code dynamically without running the risk of completely compromising its security.
This is why it's just not possible to securely serve code that does crypto in a web app. Browser extensions are the next step up, but they also have to be careful to never load code from any external locations (among other considerations they have to make when running in a browser environment).
They say it's open source, but I can't find links to the source anywhere. Anyone?
We'll add compatibility with existing PGP soon!
JavaScript encryption just isn't really valid in browsers...the browser runtime is to blame. Its funny that people have to all learn the same lessons over and over again...it's a worthwhile goal...keep at it, just try a different approach.
That pretty much defines what the field of computer security is. From DES to AES, we learned the same lesson: As things designed to be secure are put out in the real world, with sufficient enough time, they're broken. It's important not to make the same mistakes again and again, and that's nearly impossible to do with JS-Crypto since there are so many permutations of platform X on implementation (browser) Y. As long as the numbers of platforms is large and the numbers of browsers are large, having one implementation that works properly in all platforms isn't practical.
However, a specific implementation targeted at a specific browser/platform could be vetted provided the JS engine handles random numbers in a cryptographically sound manner. Ideally, the browsers would expose ways to call vetted cryptographic APIs directly via JS.
pgp works because it transfers data and not code.
Edit: Also links you to xkcd if you pick a crappy password: http://i.imgur.com/TJ3QPP7.png