Live data from Hacker News

Scramble.io: secure email for everyone

dcposch.github.io

121–130 of 142 posts

Re: Scramble.io: secure email for everyone

#121
post #46
post #40

Earlier quoted context omitted.

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 al…

It is impossible. The features required to make browser Javascript safe for crypto aren't even on the roadmaps of browser vendors. 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…

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.

Re: Scramble.io: secure email for everyone

#122

Earlier quoted context omitted.

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 miss…

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.

Re: Scramble.io: secure email for everyone

#123

Earlier quoted context omitted.

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 miss…

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.

[deleted]

Re: Scramble.io: secure email for everyone

#124

Earlier quoted context omitted.

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.

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

Re: Scramble.io: secure email for everyone

#125
post #36

Earlier quoted context omitted.

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?

While plenty of comments here are snarky, I didn't think that particular question was.

Thanks, I wasn't, indeed. Just curious, and the answers are interesting. Pity that most people here see trolling where there's just questions.

Re: Scramble.io: secure email for everyone

#126

Earlier quoted context omitted.

I think you're going to be disappointed. The only way this could work is based on network participants, and that's highly subjective. But here's an idea that might be plausible. 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 clos…

What do you mean by "The only way this could work is based on network participants, and that's highly subjective." ?

If you design based on trusting other nodes (committee and/or trusted peer groups), you have to inherently trust those nodes, and they have to be highly reliable/available, which is kind of ridiculous if you're trying to account for things like oppressive nation states.

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.

Re: Scramble.io: secure email for everyone

#127
post #23

Earlier quoted context omitted.

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 the…

Wow, thanks. Glad I could help.

Re: Scramble.io: secure email for everyone

#128

Earlier quoted context omitted.

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

Re: Scramble.io: secure email for everyone

#129
post #31

Earlier quoted context omitted.

Because it would be deeply irresponsible for them to do that.

Why?

You can't serve dynamically-loaded crypto code. What happens when someone hacks gmail and replaces crypto.aes.js with crypto.plaintext.js and suddenly every gmail user who thought they were sending encrypted mail are just sending plaintext messages?

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

Re: Scramble.io: secure email for everyone

#130
post #88
post #72

Earlier quoted context omitted.

Even with the brute protection provided by scrypt, it's very worrying that you can assume the encrypted private key will A) Be available to authorities via (secret) court order B) Captured and stored by NSA types. The security of the key could only be assumed to be as high as the weakest passphrase ever used by the user. With what we know about most user's password security (especially the type not already capable of…

Because only a subset of possible users has clientside storage available for keys, and this project doesn't care about security, it cares about maximizing the number of users it can obtain.

This whole thread makes me sad...
Post reply on HN