
Scramble.io: secure email for everyone - dcposch
http://dcposch.github.io/scramble
======
tptacek
Another week, another Javascript cryptography project. See:

[https://news.ycombinator.com/item?id=6637915](https://news.ycombinator.com/item?id=6637915)

[https://news.ycombinator.com/item?id=6420739](https://news.ycombinator.com/item?id=6420739)

[https://news.ycombinator.com/item?id=6353137](https://news.ycombinator.com/item?id=6353137)

[https://news.ycombinator.com/item?id=6317685](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.

~~~
dcposch
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!

~~~
tptacek
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 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!

~~~
orthecreedence
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?

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

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

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

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

------
mdip
It'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)
    

I'm going to skip the "JS crypto is bad".

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

~~~
jmccree
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 using GPG, which would seem the target market
of this) this seems like a very bad idea.

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?

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

~~~
jmccree
This whole thread makes me sad...

------
Procrastes
I understand the attraction. You want to solve this problem as if it was just
a straightforward hack. I spent a few days looking at this same problem
(harpomail.com) and abandoned it because, in then end, It seemed like I could
only provide a false sense of security to people who could conceivably lose
their lives because they trusted me.

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.

------
tehwalrus
Cool, this was the architecture I sketched in my head for a user-friendly PGP
app, although I would have offered to sync the private keys between device
clients, rather than doing it all in browser (that way, someone can opt out
and keep a key just on their phone or whatever.)

I had a damn good name, too, but good job someone else did it so I don't have
to! :)

------
frank_boyd
Encryption done in the browser?

Why would you take that risk and not encrypt in a client using GPG?

------
davedx
Fantastic. Tighten up the user interface and this should gain traction.
Checking out the Github repo now.

~~~
woah
Working on it! New interface should be out in the next few weeks. Check out
the "frontend-makeover" branch if you are interested.

~~~
davedx
Sounds great. I'd love to contribute to something like this.

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

i think if you took the tor model for private services and removed the open
circuits, and added a more evenly-distributed constant stream of garbage
messages sent to random peer addresses, it would be much less likely that any
one message could be linked to any two nodes with certainty. this would hinge
on the premise that all nodes are constantly receiving messages (mostly
garbage) at random. this would probably be a horrible thing for network
bandwidth, but luckily most e-mails are very small.

~~~
jaekwon
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!

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

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

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

~~~
jaekwon
I see. We can't provide secrecy, but I think we can provide some level of
deniability, and also make it a pain for those who are surveilling.

I'm not aware of any application that provides secrecy besides BitMessage. Are
there others?

------
brown9-2
_Users don 't have to manage and back up their keys---or even know what a key
is. Scramble does it for you._

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?

~~~
dcposch
> As a user, why would I want to delegate my key management to you?

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.

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

The only place a private key belongs to is the users machine (preferably
somewhere without internet access).

------
galapago
Code:
[https://github.com/dcposch/scramble](https://github.com/dcposch/scramble)

------
acoleman616
Whenever I see a site with the fixed background images and scrolling content
panels (where the background image is periodically visible again), I spend
more time trying to figure out what's contained in the background images
through those gaps than I do reading the content.

~~~
eCa
It's a bright night sky:
[http://dcposch.github.io/scramble/img/night_sky_bright.jpg](http://dcposch.github.io/scramble/img/night_sky_bright.jpg)

------
DanBC
What articles have you / your team had published in crypto journals? Where did
you / your team study cryptography?

The logo is a Rubik's cube. That's not a great logo for a cryptographic app
because Rubik's cubes are trivially solvable.

------
gnidan
I'm glad to see more projects taking off with the goal of secure email.

I found it really annoying that this service has xkcd style password
requirements. My 9-character password with non-alphanumeric characters should
be sufficient.

------
JulianMorrison
Unvetted cryptography is worth 1 cereal packet sekrit decoder ring.

~~~
mdip
Precisely which vetted, client side, JS crypto library would you prefer the
authors use to satisfy your concerns? I haven't looked at the code, and only
recently started paying attention to the JS-Crypto space. I'm aware of
implementations where scrypt was compiled to target the asm.js subset,
however, this doesn't really mean the resulting JS running on platform x, in
browser y is as secure as the resulting binary on the platform/OS it was
targeted for.

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

~~~
JulianMorrison
This is like printing "may contain arsenic" on candy.

------
ihsw
Now the question is -- why doesn't Google do this with Gmail?

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

~~~
jamiek88
Why?

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

------
jrochkind1
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?

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

~~~
jrochkind1
Yes, I agree; the fact that it's unclear if it's possible is what makes it the
holy grail, it's unclear if the holy grail actually exists, but lots of people
really want it. :)

------
lazyant
how do I create/add the public key of a contact?

~~~
jaekwon
We plan to add functionality soon! As well as exporting your public/private
key.

~~~
mnx
Soo... there's no way to actually send/recieve encrypted emails right now?

~~~
dcposch
All email from one Scramble address to another is encrypted+signed.

We'll add compatibility with existing PGP soon!

------
blahbl4hblahtoo
If you just expose your service as an API then you don't have to worry about
users trusting code given to them by the site. Then use a native client app
that doesn't suck to interact with the service...all of the encryption is done
client side with all of the messages being encrypted end to end.

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.

~~~
mdip
_Its [sic] funny that people have to all learn the same lessons over and over
again_

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.

~~~
jaekwon
That's already happened w/ the crypto.getRandomNumber function, which
openpgp.js uses/

~~~
blahbl4hblahtoo
That really doesn't change the equation. That's only if you can trust the
client code...and it just isn't feasible with JS sent to you from a 3rd party.

pgp works because it transfers data and not code.

------
special
It prompts you if you try to send an email to someone without using their
public key. I dig it.

Edit: Also links you to xkcd if you pick a crappy password:
[http://i.imgur.com/TJ3QPP7.png](http://i.imgur.com/TJ3QPP7.png)

