Perhaps I'm ignorant, but I've read your "JS crypto considered harmful post" and I disagree with the key points.

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?

We are not talking about crypto done in browser extensions. We're talking about a project that knows about extensions, knows how to package their project as an extension, but refuses to do so, because that would cost them users, who generally don't want to install extensions.

Let's try to keep things friendly, or at least correct. We haven't refused anything. Everything is on the table.

Your partner, just upthread, explained why you tabled the idea of using a browser extension to house all the logic for your app. I think your argument is with them, not me.

You falsely accused us of refusing to offer a browser extension for fear of losing users. Again, that is false.

Java, Python, etc don't have a DOM to consider.

When you're just an XSS away from an attacker doing:

  function encrypt(plaintext) {
    $.post(plaintext, ...);
    return plaintext;
  }

then you lose. The post talks about this, and XSS isn't the only way either.

If all of the Javascript code and application functionality is bundled into the add-on, it's trivial to avoid XSS. There's no "site" to script into via the URL, and rendering of dynamic elements can be done via a sandboxed iFrame, preventing any scripts from running within dynamic data. This is fairly basic security that any add-on developer should be aware of: http://developer.chrome.com/apps/sandboxingEval.html

"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.

I don't like the article either, but you're wrong about it being "extremely out of date", and you'd have a very hard time defending your argument with evidence. Do try.

Right, but an attacker needs access to the DOM first. If everything is packaged, this is just as difficult as being able to inject random python code.

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.

Right, like getting access to the DOM was ever a hard thing to do. I was specifically referring to web apps in that point, but because you insist, I'll just reference [1].

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...

Cache poisoning won't work if an extension loads all of its code from its own bundle. So I fail to see how this applies to an app that is fully self-contained within an extension (extensions themselves are signed, so it's not like you could MitM the extension bundle itself...)

> it's fatal to security

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 (a) don't have a Chrome extension that verifies anything right now, (b) are currently publishing the pure- browser- JS version of your application, and (c) envision a future in which a small number of "power users" can "safely" use the system while the majority of users, who you correctly note will not install your extension, will be at the mercy of attackers or, for that matter, your own server.

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.

I respect your well-considered opinions most of the time, but here, you seem to not really be presenting anything constructive. "Javascript doesn't have the features needed to be secure" Which features? Enlighten us.

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.

But doesn't this approach if implemented the best we can , at least blocks dragnet surveillance ? isn't that valuable ?

How are you going to block dragnet surveillance if they can surveil the method of your delivering encrypted messages? NSA can already see, and modify, the JS used to create encrypted messages (because they've owned the HTTPS gateways), so they can see, and modify, the encrypted messages.

If they do this for many users, then those who don't have a secure environment (including the browser extension) are vulnerable, but it would be easy to detect that this is happening on a large scale -- those running the extension would be notified. If they don't do this for every user, then it wouldn't be effective dragnet surveillance, and Scramble would have a made a dent in dragnet ability.

Let's stipulate that your detection system, which does not currently exist even as a design document, actually works. By your own admission, only a small minority of users will actually install it. Now: a whistleblower in the USG, who is much more likely not to be a "power user" (if they were clueful they wouldn't be using this system to begin with) leaks a document from your service to a journalist and begins a conversation.

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.

Tptacek, whistle blowers level security should not be a use case for this extension , and should be advertised as part of it.

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 think the disconnect here is, many of us can't imagine offering something with known technical security issues such as browser side JS encryption, and branding that "secure". Much less with all the unknown legal, operational, and techical security issues that may arise later in a project like this. As well, from what I read this project transfers your (encrypted with only a passphrase) private key over the internet, where it will be caught in the dragnet for decryption later.

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...

Its not a personal insult. This system just doesn't provide serious protection from "dragnet surveillance". Distributing keys and allowing the client to encrypt a message to another user ala GPG is a great idea...you just can't use server delivered code to do it in the traditional web server/browser way. The JavaScript is modifiable in transit.

Could you be more specific? I don't know who "everyone" is, or what a large scale is, or who is detecting what by whom. In any case, I don't see how anyone could detect real HTTPS MITM.

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.

We assume that the server is compromised, so the extension wouldn't interpret just any JS from the server, whether or not it was delivered by HTTPS. Our idea is to require a committee to review and sign the code, and the extension would only execute code signed by the committee in consensus. This is just as secure as shipping all of the program logic in the extension, except in the case where all the signing committee member keys get compromised, which is unlikely.

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.

So far, i've failed to see a reliable committee-signing trust system. Moxie's Convergence blows chunks all over my network connections in practice.

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.