Scramble servers store only ciphertext. This means that nobody, not even the operator of a Scramble server, can read your mail. 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.) Mail sent from one Scramble address to another is OpenPGP encrypted and signed in your browser—so the server never sees plaintext.
Scramble includes a user-friendly webmail interface. You can check your email from anywhere. Scramble can also exchange unencrypted email with existing email addresses. This is not as secure as communication between two Scramble servers, but it allows you to use Scramble as your email provider right away. Even plaintext email is encrypted before being stored--so while an attacker could wiretap such mail going forward, nobody can read email you've received after the fact.
Scramble is open source. Anyone can run a Scramble server. For example, an organization could run one for its members. Mail from any Scramble address to any other is always encrypted and signed.
Most existing email systems only encrypt data during transmission, but get stored as plaintext on the mail-server. Other email systems like Lavabit also encrypt the email before storage, but are encrypted on the server in such a way that the server operator could obtain the plaintext. Scramble servers have no knowledge of the message contents, since encryption is always performed end-to-end on the clients.
When a user first registers on a Scramble server, an OpenPGP keypair is generated on the client. The public key of the recipient is used for encrypting email, and the key of the sender is used for authentication. The private key of the recipient is decrypts the message. Users don't have to manage and back up their keys---or even know what a key is. Scramble does it for you.
Private keys are stored on the server in encrypted form. The key derivation function used is as follows:
K = scrypt(Passphrase, Username)where
Passphrase is the user’s secret login passphrase and Username serves as the salt.
Keypair generation and ephemeral symmetric key generation depends on using the HTML5 crypto.getRandomValues() strong random number generator. Modern browsers come with a basic crypto API.
Each Scramble address is associated with a public key. In order to encrypt a message for a recipient, and in order to verify the authenticity of a received message, the Javascript client needs to resolve a Scramble address and retrieve the public key. Doing this securely is difficult!
The established way to do this with PGP today is with the web-of-trust model. Identities are endorsed by other identities via cryptographic signatures. You are encouraged to do this in person (e.g. at key signing parties) where you can see the person and her public key together. The problem with this approach is that the web-of-trust is cumbersome to build up. Existing OpenPGP clients have serious usability issues, so relatively few people bother to use them, and most people are left unprotected.
Scramble uses an alternative federated trust model inspired by Moxie's Convergence.io project. To look up a public key, the client asks a set of notaries---ideally ten or more, run by independent organizations and in different countries. If enough of them answer and they all agree, then the response is trusted. An attacker can't pretend to be a notary: the client comes with a public key for each trusted notary, and the notaries sign their responses. This allows the client to verify. Unlike, say, Namecoin, adding a new address-to-public-key mapping to the notaries is free and easy.
For our prototype release, we're running three initial notaries, all located in California. We're looking for volunteers--especially outside the US--who can run additional notaries.
Scramble aims to provide strong security guarantees without compromising on usability. Webmail is the easiest way to reach a wide audience, but it comes with its own set of challenges. Once you have a trusted client, our design doesn't require you to trust the server. 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. To solve this problem, we are going to develop a browser extension. This extension will run the same client—the same HTML, CSS, and Javascript—but verify that each file is signed. It will be seamless for webmail users to upgrade to the extension, and we can give them a few additional usability benefits. For example: users will be notified when a new email arrives without always having to keep a tab open.
Unforunately, while OpenPGP can encrypt the contents of your emails—and, the way Scramble uses it, even the subject lines—you still leak From and To. In other words, an adversary may not see what you're saying, but they can see who you're talking to.
Strong metadata secrecy does not seem possible over SMTP. At a minimum, the To header must be there for all to see, otherwise your email won't arrive. Brand-new protocols have been proposed, notably BitMessage. The Dark Mail Alliance is also attempting strong metadata secrecy, though they haven't described their approach yet. Staying interoperable with email and existing PGP users has lots of benefits, hence our decision.
Users with strong security requirements can still have pseudo-anonymity. For example: a news organization might use contact@<news-organization>.org without revealing the journalist behind it. A famous example of a pseudo-anonymous address is satoshi@gmx.com, the creator of Bitcoin, whose real identity is not known. Such users could access Scramble over Tor, thus not revealing their physical location even assuming a compromised server.
Remember that this is a work in progress. Do not use Scramble.io for sensitive information yet.
We're building a standard email client, designed for security. We're building a novel notary system so that OpenPGP key exchange can be effortless. We want encryption to be the default, not the exception. Join us!
Jaekwon and DC
{dcposch, jaekwon}@scramble.io