Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scramble.io: secure email for everyone

dcposch.github.io

Post reply on HN
Print view View original

91–100 of 142 posts

Re: Scramble.io: secure email for everyone

#91

Post by hershel »

tptacek wrote: post #86
jaekwon wrote: post #77

Earlier quoted context omitted.

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

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 ?

Re: Scramble.io: secure email for everyone

#92

Post by jaekwon »

tptacek wrote: post #83
jaekwon wrote: post #79

Earlier quoted context omitted.

What you said applies more to you than it does to me.

Usually, when people claim to have refuted our crappy old article on Javascript crypto, they have some misguided but at least potentially falsifiable argument for having accomplished that; for instance, "there are browsers with secure RNGs now". 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 tha…

My argument is this: "This is also a PGP application that most people can benefit from immediately (compared to using Hotmail), and one that can be used by even the most targeted users if their environment is set up correctly once the extension is out."

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.

Re: Scramble.io: secure email for everyone

#93

Post by hershel »

eli wrote: post #89
hershel wrote: post #84

Earlier quoted context omitted.

>> I want to make it as easy as possible for users to try out and adopt. Just testing it out? No installation required. 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 vari…

I think you can do that now with one of the GPG browser plugins (or just copy/pasting from a GPG app)

It's different when everything is integrated , drive much much more usage, which is the whole point.

Re: Scramble.io: secure email for everyone

#94

Post by tptacek »

jaekwon wrote: post #81
jahewson wrote: post #37

Earlier quoted context omitted.

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.

A secure environment would require a vetted browser and no other hostile extensions. That's certainly possible, so Scramble does have a use.

I see. So, if I set up an intricate browser clean-room environment, and I assume that the Javascript verification system you come up with actually works, I can get some of the benefit of simply installing GPG and using POP mail.

Re: Scramble.io: secure email for everyone

#95

Post by blahbl4hblahtoo »

jrochkind1 wrote: post #34

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

I have to disagree. I'm not sure that is the "holy grail"...i think its not even possible with common browser runtimes.

Re: Scramble.io: secure email for everyone

#96

Post by jaekwon »

peterwwillis wrote: post #87
jaekwon wrote: post #77

Earlier quoted context omitted.

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.

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…

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.

Re: Scramble.io: secure email for everyone

#97

Post by peterwwillis »

jaekwon wrote: post #90
peterwwillis wrote: post #76

so, you want to send someone a message. you don't care if someone sees you sending it. but you don't want anyone to know whom you sent it to, or what the message contains. 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.…

Yes, we're on the same page! We have an idea for how fake messages would be passed around fake friends, and how to grow this "dark" network organically. Let's collaborate!

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

Re: Scramble.io: secure email for everyone

#98

Post by blahbl4hblahtoo »

hershel wrote: post #91
tptacek wrote: post #86

Earlier quoted context omitted.

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

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…

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.

Re: Scramble.io: secure email for everyone

#99

Post by peterwwillis »

jaekwon wrote: post #96
peterwwillis wrote: post #87

Earlier quoted context omitted.

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…

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

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.

Re: Scramble.io: secure email for everyone

#100

Post by orthecreedence »

tptacek wrote: post #46
dcposch wrote: 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…

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?

Post reply on HN