diff --git a/LEIAME.md b/LEIAME.md index 2f57b53..e32d357 100644 --- a/LEIAME.md +++ b/LEIAME.md @@ -1,3 +1,10 @@ +WARNING: This document is no longer up to date and contains a large number of inaccuracies. Please read the english original. +=========================================================== + + + + + Há um número crescente de projetos trabalhando na próxima geração de e-mail seguro ou de comunicação semelhante ao e-mail. Esse é um rascunho inicial de um relatório destacando os projetos e comparando as suas abordagens. Por favor, ajude-nos a completar os detalhes que faltam e corrijam qualquer imprecisão. Para contribuir com esse documento, faça um fork desse repositório e faça pull request. Conteúdo: diff --git a/LIESMICH.md b/LIESMICH.md index 4c78a3c..0edfd04 100644 --- a/LIESMICH.md +++ b/LIESMICH.md @@ -1,3 +1,8 @@ +WARNING: This document is no longer up to date and contains a large number of inaccuracies. Please read the english original. +=========================================================== + + + Eine zunehmende Zahl an Projekten arbeiten an einer neuen Generation für sichere Emails oder E-Mail-artiger Kommunikation. Dieser Bericht stellt die Projekte vor und vergleicht ihre Ansätze. Bitte hilf uns fehlende Details zu ergänzen und alle Fehler zu korrigieren. Um an diesem Dokument mitzuarbeiten, verwende die fork & pull-Funtkionalität von github. Contents: diff --git a/README.md b/README.md index 541ad8f..eeff15c 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,17 @@ -There are an increasing number of projects working on next generation secure email or email-like communication. This is an initial draft report highlighting the projects and comparing the approaches. Please help us fill in the missing details and correct any inaccuracies. To contribute to this document, fork this repository and issue a pull request. +There are an increasing number of projects working on next generation secure email or email-like communication. Only few of them fulfil the [security requirements](http://libreplanet.org/wiki/GNU/consensus/berlin-2013) of the #[youbroketheinternet](http://youbroketheinternet.org) community. This is a report highlighting the projects and comparing the approaches. Please help us fill in the missing details and correct any inaccuracies. To contribute to this document, fork [its repository](https://github.com/symlynX/secure-email). This document is hosted at [youbroketheinternet.org](http://youbroketheinternet.org/secure-email), since it is bad practice to host content exclusively at commercial social networks. Contents: +1. [Executive Summary](#tldr) 1. [Common Problems](#common-problems) 1. [Key Management](#key-management) - 1. [Metadata Protection](#metadata-protection) + 1. [Protection of Transaction Data and the Social Graph](#metadata-protection) 1. [Forward Secrecy](#forward-secrecy) 1. [Data Availability](#data-availability) 1. [Secure Authentication](#secure-authentication) + 1. [Installation and Bootstrap](#installation) + 1. [Scalability](#scalability) + 1. [Social Usability](#social-usability) 1. [Web Mail](#web-mail) 1. [Mega](#mega) 1. [PrivateSky](#privatesky) @@ -24,21 +28,39 @@ Contents: 1. [Dark Mail Alliance](#self-hosted-dark-mail) 1. [FreedomBox](#freedombox) 1. [Mailpile](#self-hosted-mailpile) + 1. [Mail-in-a-box](#mail-in-a-box) 1. [kinko](#kinko) 1. [Email Infrastructure](#email-infrastructure) 1. [Dark Mail Alliance](#dark-mail-alliance) 1. [LEAP Encryption Access Project](#leap) -1. [Post-email alternatives](#post-email-alternatives) - 1. [Bitmessage](#bitmessage) +1. [Public-Key Routing Systems](#public-key-routing) + 1. [Briar](#briar) 1. [Cables](#cables) - 1. [Dark Mail Alliance](#p2p-dark-mail-alliance) + 1. [cjdns and net2o](#cjdns-net2o) 1. [FlowingMail](#flowingmail) + 1. [Freemail](#freemail) 1. [Goldbug](#goldbug) + 1. [I2P-Bote](#i2pbote) 1. [Pond](#pond) + 1. [Retroshare](#retroshare) + 1. [secushare](#secushare) 1. [Unclassified](#unclassified) - 1. [Startmail](#startmail) + 1. [Bitmessage](#bitmessage) + 1. [Dark Mail Alliance](#p2p-dark-mail-alliance) + 1. [Susimail](#susimail) 1. [Related Works](#related-works) +TL;DR: Executive Summary +=========================================================== + +Traditional email faces unsurmountable problems concerning trustworthiness, usability and protection of social information on who is participating in communications when it comes to provide end-to-end confidentiality. Even the best projects in the field accept dangerous trade-offs such as 1. allowing for man in the middle attacks at the moment of first use, 2. allowing people who disregard your privacy requirements to send you unencrypted messages, 3. allowing observing entities to map out the identities and the intensity of social interactions, 4. requiring a complete overhaul of the involved protocols if forward secrecy is to be achieved and 5. to tackle incongruencies in the architecture with user interface design, as if that hadn't been tried in the previous twenty years. Also, none of the improvements tackle the problem that people are flocking away to Facebook Mail, a cloud- and social-network-based alternative that offers 6. better usability, 7. user-expectation conformant scalability and 8. freedom from Spam and correlated nuisances. + +It is not surprising that projects that started over a decade ago re-inventing the foundation of the Internet based on public-key routing and distributed hashtable technology, have in the meantime developed to a degree of solidity that they are presenting a true alternative way for many Internet applications including email. These technologies solve several of the problems of traditional email by design, other are in the process of being resolved, but since the science community has made very in-depth research on the issues involved with public-key based routing, the methods are known and already implemented in some projects. + +It is reasonable to conclude that to improve and deploy such fundamentally new technology is lower hanging fruit than to further attempts of repairing the old broken architecture, but there is very emotional resistance in the systems administrators community to this kind of conclusion. If you think you need to make up your mind for yourself, this document is for you. + +Still, the alternative mail systems that fulfil the privacy requirements of #youbroketheinternet today are [Cables](#cables), [Freemail](#freemail), [I2P-Bote](#i2pbote) and [Pond](#pond). None of them however also fulfil the scalability and social usability aspects. These will be addressed by future technologies currently in the making. + Common Problems =========================================================== @@ -47,43 +69,43 @@ All of the technologies listed here face a common set of problems when trying to Key Management ----------------------------------------------------------- -All the projects in this report use public-key encryption to allow a user to send a confidential message to the intendant recipient, and for the recipient to verify the authorship of the message. Unfortunately, public-key encryption is notoriously difficult to use properly, even for advanced users. The very concepts are confusing for most users: public key versus private key, key signing, key revocation, signing keys versus encryption keys, bit length, and so on. +All the projects in this report use public-key encryption to allow a user to send a confidential message to the intended recipient, and for the recipient to verify the authorship of the message. Unfortunately, in traditional approaches to email, public-key encryption is notoriously difficult to use properly, even for advanced users. The very concepts are confusing for most users: public key versus private key, key signing, key revocation, signing keys versus encryption keys, bit length, and so on. Newer systems hide this complexity from the user, at the cost of being incompatible to the old methods, but since most of humanity doesn't know a single person who uses encrypted email, that is hardly a criterion. -Traditionally, public key cryptography for email has relied on either the X.509 Certificate Authority (CA) system or a decentralized "Web of Trust" (WoT) for key validation (authenticating that a particular person owns a particular key). Recently, both schemes have come under intense criticism. Repeated security lapses at many of the Certificate Authorities have revealed serious flaws in the CA system. On the other hand, in an age where we better understand the power of social network analysis and the sensitivity of the social graph, the exposure of metadata by a "Web of Trust" is no longer acceptable from a security standpoint. +Traditionally, public key cryptography for email has relied on either the X.509 Certificate Authority (CA) system or a decentralized "Web of Trust" (WoT) for key validation (authenticating that a particular person owns a particular key). Recently, both schemes have come under intense criticism. Repeated security lapses at many of the Certificate Authorities have revealed serious flaws in the CA system. On the other hand, in an age where we better understand the power of social network analysis and the sensitivity of the social graph, the exposure of metadata by a publicly available "Web of Trust" is no longer acceptable from a security standpoint. Such information must only be available to the people involved, which puts limitations to the acceptable depth of the view of the social graph. -This is where we are now: we have public key technology that is excessively difficult for the common user, and our only methods of key validation have fallen into disrepute. The projects listed here have plunged into this void, attempting to simplify the usage of public-key cryptography. These efforts have four elements: +This is where we are now: we have public key technology that is excessively difficult for the common user in the way it works with the email infrastructure, and our traditional methods of key validation have fallen into disrepute. The projects listed here have plunged into this void, attempting to simplify the usage of public-key cryptography. These efforts have four elements: -* Key discovery: There is no commonly used standard for discovering the public key attached to a particular email address. All the projects here that use OpenPGP intend to initially use, as a stop-gap measure, the OpenPGP keyservers for key discovery, although the keyserver infrastructure was not designed to be used in this way. -* Key validation: If not Certificate Authorities or Web of Trust, what then? Nearly every project here uses Trust On First Use (TOFU) in one way or another. With TOFU, a key is assumed to be the right key the first time it is used. TOFU can work well for long term associations and for people who are not being targeted for attack, but its security relies on the security of the discovery transport and the application's ability to retain a memory of discovered keys. TOFU can break down in many real-world situations where a user might need to generate new keys or securely communicate with a new contact. The projects here are experimenting with TOFU in different ways, and these problems can likely be mitigated by combining TOFU with other measures. -* Key availability: Almost every attempt to solve the key validation problem turns into a key availability problem, because once you have validated a public key, you need to make sure that this validation is available to the user on all the possible devices they might want to send or receive messages on. -* Key revocation: What happens when a private key is lost, and a user want to issue a new public key? None of the projects in this report have an answer for how to deal with this in a post-CA and post-WoT world. +* Key discovery: There is no commonly used standard for discovering the public key attached to a particular email address. All the SMTP-based projects intend to initially use, as a stop-gap measure, the OpenPGP keyservers for key discovery, although the keyserver infrastructure was not designed to be used in this way. Newer strategies for discovery are the exchange of public keys 1. using a graphic depiction of the public key (usually QR codes) printed on business cards or brochures, 2. by bringing end devices into bluetooth range of each other, 3. by adopting new people from a trusted person's social vicinity. +* Key validation: If not Certificate Authorities or Web of Trust, what then? Nearly every SMTP-based project uses Trust On First Use (TOFU) in one way or another. With TOFU, a key is assumed to be the right key the first time it is used. TOFU can work well for long term associations and for people who are not being targeted for attack, but its security relies on the security of the discovery transport and the application's ability to retain a memory of discovered keys. TOFU can break down in many real-world situations where a user might need to generate new keys or securely communicate with a new contact. The projects here are experimenting with TOFU in different ways, and these problems can likely be mitigated by combining TOFU with other measures. Still there are ways to avoid TOFU as indicated by at least three methods mentioned above: 1. printed QR code, 2. bluetooth exchange, 3. social adoption. Additionally there are validation strategies based on shared secrets. It is however a good design choice to not separate key discovery from validation or otherwise validation becomes a bureaucratic extra transaction that people will be too lazy to execute. Both TOFU and shared secret should therefore be discontinued in favor of the three stronger authentication methods. +* Key availability: Almost every attempt to solve the key validation problem turns into a key availability problem, because once you have validated a public key, you need to make sure that this validation is available to the user on all the possible devices they might want to send or receive messages on. For systems that route by public key this is only a question of synchronizing address books, since there is no distinction between a person and her public key. +* Key revocation: What happens when a private key is lost, and a user wants to issue a new public key? Of all the projects in this report, only one has an answer for how to deal with this in a post-CA and post-WoT world: All users need to generate master keys that they will hardly ever use in everyday life and have all day-to-day use keys derived from those. secushare's strategy for storing the master key safely is to print it out on a QR code for the user to hide in a safe place in the house, then remove the key material from computer memory. This way the user can recover her identity by recovering her master key, issuing revocations for derived keys and bring new ones in circulation. -Metadata Protection +Protection of Transaction Data and the Social Graph ----------------------------------------------------------- -Traditional schemes for secure email have left metadata exposed. We now know that metadata is often more sensitive than message content: metadata is structured data, easily stored forever, and subject to powerful techniques of social network analysis that can can be incredibly revealing. +Traditional schemes for secure email have left transaction data and the social graph of people exposed. The NSA prefers to use the term metadata, as it sounds less dramatic. We now know that metadata is often more sensitive than message content: metadata is structured data, easily stored forever, and subject to powerful techniques of social network analysis that can can be incredibly revealing. -Metadata protection, however, is **hard**. In order to protect metadata, the message routing protocol must hide the sender and recipient from all the intermediaries responsible for relaying the message. This is not possible with the traditional protocol for email transport, although it will probably be possible to piggyback additional (non-backward compatible) protocols on top of traditional email transport in order to achieve metadata protection. +Metadata protection, however, is **hard**. In order to protect metadata, the message routing protocol must hide the sender and recipient from all the intermediaries responsible for relaying the message. This is not possible with the traditional protocol for email transport, although it will probably be possible to piggyback additional (non-backward compatible) protocols on top of traditional email transport in order to achieve metadata protection. Still a clean slate approach is probably going to be safer from a security standpoint. -Alternately, some projects reject traditional email transport entirely. These decentralized peer-to-peer approaches to metadata protection generally fall into four camps: (1) directly relay the message from sender's device to recipients device; (2) relay messages through a network of friends; (3) broadcast messages to everyone; (4) relay messages through an anonymization network such as Tor. The first two approaches protect metadata, but at the expense of increasing vulnerability to traffic analysis that could reveal the same metadata. The third solution faces serious problems of scalability. Pond uses the fourth method, discussed below. +In fact, many projects reject traditional email transport entirely and replace it with public-key based routing, frequently confused with peer-to-peer. These approaches to metadata protection generally fall into four camps: (1) directly pass the message from sender's device to recipients device by physical interaction; (2) relay messages through a network of socially interwoven nodes; (3) broadcast messages to everyone; (4) relay messages through an anonymization network such as Tor. The third solution faces serious problems of scalability. -All schemes for metadata protection face the prospect of increasing Spam (since one of the primary methods used to prevent Spam is analysis of metadata). This is why some schemes with strong metadata protection make it impossible to send or receive messages to anyone you are not already in contact with. This works brilliantly for reducing Spam, but is unlikely to be a viable long term strategy for entirely replacing the utility of email. +All schemes that do not combine metadata protection with the implicit rejection of messages from socially unrelated strangers face the prospect of increasing Spam, since one of the primary methods used to prevent Spam is analysis of metadata. Some projects like Retroshare, Briar and in particular secushare compensate for this by offering social-graph-based discovery of contacts, thus allowing to introduce yourself to someone via first or possibly second degree of common contacts. Forward Secrecy ----------------------------------------------------------- -Forward secrecy is a security property that prevents an attacker from saving messages today and then later decrypting these messages once they have captured the user's private key. Without forward secrecy, an attacker might also be able to capture messages today and simply wait for computers to become powerful enough to crack the encryption by brute force. Traditional email encryption offers no forward secrecy. +Forward secrecy is a security property that prevents an attacker from saving messages today and then later decrypting these messages once they have captured the user's private key. Traditional email encryption offers no forward secrecy. -All methods for forward secrecy involve a process where two parties negotiate an ephemeral key that is used for a short period of time to secure their communication. In many cases, the ephemeral key is generated anew for every single message. Traditional schemes for forward secrecy are incompatible with the asynchronous nature of email communication, since with email you still need to be able to send someone a message even if they are not online and ephemeral key generation requires a back and forth exchange between both parties. +All methods for forward secrecy involve a process where two parties negotiate an ephemeral key that is used for a short period of time to secure their communication. In many cases, the ephemeral key is advanced or generated anew for every single message. Ephemeral key generation requires a back and forth exchange between both parties to get started, which may be impractical at first if they aren't online at the same time. Once started the problem no longer exists. -There are several new experimental (and tricky) protocols that attempt to achieve both forward secrecy and support for asynchronous communication, but none have yet emerged as a standard. Another possible approach is to use traditional encryption with no support for forward secrecy but instead rely on a scheme for automatic key discovery and validation in order to frequently rotate keys. This way, a user could throw away their private key every few days, achieving a very crude form of forward secrecy. +Another possible approach is to use traditional encryption with no support for forward secrecy but instead rely on a scheme for automatic key discovery and validation in order to frequently rotate keys. This way, a user could throw away their private key every few days, achieving a very crude form of forward secrecy. That could work if the key discovery methods were safe and trustworthy. Data Availability ----------------------------------------------------------- Users today demand data availability: they want to be able to access their messages and send messages from any device they choose, wherever they choose, and whenever they choose. Most importantly, they don't want the loss of any particular device to result in a loss of all their data. For insecure communication, achieving data availability is dead simple: simply store everything in the cloud. For secure communication, however, we have no proven solutions to this problem. As noted above, the key management problem is also really a data availability problem. -Most of the projects here have postponed dealing with the data availability problem. A few have used IMAP to synchronize data or developed their own secure synchronization protocol. +Most of the projects here have postponed dealing with the data availability problem. A few have used IMAP to synchronize data or developed their own secure synchronization protocol. secushare uses anonymized distribution trees over relay nodes, thus enabling all devices to access the data safely from a socially powered kind of cloud. Secure Authentication ----------------------------------------------------------- @@ -97,6 +119,31 @@ For those projects that make use of a service provider, one of the key problems No consensus or standard has yet emerged, although SRP has been around a while. +Installation and Bootstrap +----------------------------------------------------------- + +As we will show, having a proper, safe, end-to-end encryption experience, which also achieves goals such as protecting transaction data, cannot happen without a software installation. Be it a new client software, an embeddable encryption tool, a cryptographic routing infrastructure or an improved client/server coupling. + +Also, since more than 99% of population hasn't been using any encryption so far, the social bootstrap procedure will be starting from zero for most users. It is thus important to note that there is no gain in installing a technology which is compatible to the old email system: It re-introduces old threats and complicates user interfaces, even if there was a way to add encryption to the existing system that makes sense. [PGP over SMTP doesn't](http://secushare.org/PGP). + +For the 99% it makes more sense to simply start using a different software for secure messaging while also participating in the old email system using whatever insecure user interface they have been using so far. At some point they will have a sufficient number of contacts on the new system that they will use the old one less and less, just like people migrated from Myspace to Facebook. + +So it is a common challenge for all the projects to make installation and bootstrap as easy as possible. + +Scalability +----------------------------------------------------------- + +Limitations in scalability are traditionally accepted in e-mail. Should you need to send a message to a mailing list of ten thousands of users, it is accepted that your server will be busy all day doing just that. Should you instead own an account at Google Mail and happen to have a mailing list of a million other Google users, then it is accepted that the message will be distributed in a question of seconds. + +This discrepancy is due to the federated architecture of SMTP known not to scale very well while a mail system which is fully internal to a commercial cloud can make use of advanced publish/subscribe distribution trees. Some advanced email replacements also take this aspect in consideration and try to improve on the scalability of email by introducing anonymized distributed publish/subscribe strategies. Frequently they also include the capability of delivering binary encoded data natively, thus reducing in encoding overhead compared to email's MIME formats. + +Social Usability +----------------------------------------------------------- + +Email is currently losing millions of users to social network offerings such as Facebook, simply because it is fully integrated into a social experience, easier to handle (requires no addresses), visually more appealing (it shows the communication partner's photograph), less asynchronous (if both are online, it turns into a real-time chat) and generally less formal. + +Ignoring these large usability improvements provided by the integration into a social experience could result in new mail systems failing to reach for the large audience of people who don't put security first. Some projects address this by integrating the new mail experience in an advanced social networking experience, also allowing to simplify the adoption of public keys from the list of a friend's friends as an alternative to more cumbersome methods of key authentication. + Web Mail =========================================================== @@ -111,6 +158,8 @@ Second, even if the application is loaded from a trusted third party, web browse Third, developers of web-based secure email face an additional challenge when dealing with offline data or data caching. Modern HTML5 apps typically store a lot of data locally on the user's device using the localStorage facility. Currently, however, no browser stores this encrypted. A secure web-based email application must either choose to not support any local storage, or develop a scheme for individually encrypting each object put in localStorage, a process which is very inefficient. Even storing keys temporarily in short lived session storage is problematic, since these can be easily read from disk later. +Some of the new mail systems and mail clients avoid all of the problems above by offering their web interface over a little web server installed on the same computer or device the web browser is running on. In that case all the sensitive data can stay on the native application even if the user interface seems to be a web site. Those are not considered actual "web mail" in this document and therefore appear in following chapters. + Mega ----------------------------------------------------------- @@ -132,14 +181,12 @@ The makers of the secure search engine [startpage.com](https://startpage.com) ha Despite the tag line as the "world's most private email," StartMail is remarkably insecure. If offers regular IMAP service and a webmail interface that supports OpenPGP, but the user still must trust StartMail entirely. For example when you authenticate, your password string is sent to StartMail, and new OpenPGP keypairs are generated on the server, not the client. The website also makes some dubious statements, such as claiming to be more secure because their TLS server certificate supports extended validation. -Verdict: oil of snake - Scramble ----------------------------------------------------------- [scramble.io](https://scramble.io) -Scramble is a OpenPGP email application that can be loaded from a website (with plans to add app store support). Additionally, you can sign up for email service from scramble.io. +Scramble is an OpenPGP email application that can be loaded from a website (with plans to add app store support). Additionally, you can sign up for email service from scramble.io. **Keys:** Private keys are generated in the browser app, encrypted with the user's passphrase, and then stored on the server. The server never sees the user's passphrase (password is hashed using scrypt before sent to the server during account creation and authentication). The master storage secret (symmetric key) used to encrypt keys is stored in the browser's sessionStorage, which is erased when the user logs out. Keys are validated using notaries. @@ -180,7 +227,7 @@ Mailvelope is a browser extension that allows you to use OpenPGP email with trad **Application:** When the extension detects you have opened a web page from a supported web-mail provider such as Gmail, it offers the user the opportunity to encrypt what you type in the compose window and decrypt messages you receive. -**Limitations:** Because of an inherent limitation in the way Mailvelope can interface with web-mail, it is not able to send OpenPGP/MIME (although it can read it fine). As mentioned elsewhere, browser storage is not a particular ideal place to be storing keys. When a web-mail provider changes their UI (or API if they happen to have one), the extension must be updated to handle the new format. +**Limitations:** Because of an inherent limitation in the way Mailvelope can interface with web-mail, it is not able to send OpenPGP/MIME (although it can read it fine). As mentioned before, browser storage is not a particular ideal place to be storing keys. When a web-mail provider changes their UI (or API if they happen to have one), the extension must be updated to handle the new format. * Contact: info@mailvelope.com * Written in: Javascript @@ -196,8 +243,8 @@ An email client, or MUA (Mail User Agent), provides a user interface to access e There are two primary advantages to the mail client approach: -1. Existing accounts: By using a custom secure mail client, a user can continue to use their existing email accounts. -1. Tailored UI: A custom client has the potential to rethink the email user experience in order to better convey security related details to the user. +1. Existing accounts: By using a custom secure mail client, a user can continue to use their existing email accounts, although that isn't really an advantage since a key discovery and validation procedure needs to be made for each interesting contact which is just as cumbersome as adding that person on a completely different software. Also, allowing contacts to send you unencrypted messages can harm your privacy. +1. Tailored UI: A custom client has the potential to rethink the email user experience in order to better convey security related details to the user - whithin the limits imposed by the traditional email architecture (having to convey the importance of addresses, for example). The mail client approach, however, also has several disadvantages: @@ -213,9 +260,9 @@ Ultimately, the level of email security that is possible with the custom mail cl Bitmail is a desktop application that provides a user interface for traditional IMAP-based mail, but also supports a custom peer-to-peer protocol for relaying email through a network of friends. Bitmail will support both OpenPGP and S/MIME. -**Keys:** Keys are validated using a shared secret or fingerprint validation. Public keys are discovered over the p2p network. Keys are stored locally in an encrypted database. +**Keys:** Keys are validated using a shared secret or fingerprint validation. Public keys are discovered over the P2P network. Keys are stored locally in an encrypted database. -**Routing:** Bitmail uses an "echo protocol" for p2p message routing, where every message is sent to every neighbor. +**Routing:** Bitmail uses an oppurtunistic message distribution model where every message is sent to every neighbor. It is called "Echo" and it is very similar to the protocols used by Retroshare and Briar. **Application:** Bitmail uses the Qt library for cross platform UI. @@ -236,7 +283,7 @@ Note: I am unclear which of the previous features are planned and which are curr Mailpile is an email client designed to quickly handle large amounts of email and also support user-friendly encryption. The initial focus is on email, with plans to eventually support post-email protocols like bitmessage, flowingmail, or darkmail. Also, the developers hope to add support for XMPP-based chat in the future. Since the Mozilla foundation has not committed the resources necessary to keep Thunderbird contemporary, the Mailpile initiative holds a lot of promise as a cross-platform mail client that seeks to redesign how we interact with email. -**Keys:** Mailpile email encryption is based on OpenPGP (it uses your GPG keyring). Key discovery will be handled using OpenPGP keyservers and including public keys as attachments to outgoing email. Public keys are trusted on first use, with plans for validation via DANE and manual fingerprint verification (future support for a p2p protocol might include additional methods, such as Certificate Transparency or Short Authentication Strings). Currently, keys are not backed up. +**Keys:** Mailpile email encryption is based on OpenPGP (it uses your GPG keyring). Key discovery will be handled using OpenPGP keyservers and including public keys as attachments to outgoing email. Public keys are trusted on first use, with plans for validation via DANE and manual fingerprint verification (future support for a P2P protocol might include additional methods, such as Certificate Transparency or Short Authentication Strings). Currently, keys are not backed up. **Application:** Mailpile UI is written using HTML5 and Javascript, running against a self-hosted Python application (that typically lives locally on the device, but might be running on your own server). @@ -267,7 +314,7 @@ Parley is a desktop mail client with a UI written using HTML5 and Javascript, wi * Written in: Python, Javascript * Source code: https://github.com/blackchair/parley * Design documentation: https://parley.co/#how-it-works -* License: BSD +* License: BSD (with proprietary server-side dependencies) * Platforms: Windows, Mac, Linux (with Android and iOS planned). Self-Hosted Email @@ -280,12 +327,12 @@ In the United States, much of the interest in self-hosted email is driven by the Unfortunately, it is not so simple. There are some major challenges to putting email servers in everyone's home: * **Delegated reputation**: The current email infrastructure is essentially a system of delegated reputation. In order to be able to send mail to most providers and not have a large percentage of it marked as Spam, a service provider must gradually build up a good reputation. Users are able to send mail because their provider has cultivated this reputation and maintained it by closing abusive accounts. It is certainly possible to run an email provider with a single user, but it is much harder to build up a good reputation. Also, many email providers block all relay attempts from IP addresses that have been flagged as "home" addresses, on the (probable) assumption that the message is coming from a virus and not a legitimate email server. -* **Servers are on a hostile network**: Because a server needs to have open ports that are publicly accessible from the internet at all times, running one is much trickier than a simple desktop computer. It is much more critical to make sure security upgrades are applied in a timely manner, and that you are able to respond to external attacks, such as "Spam Bombs". Any publicly addressable IP that is put on the open internet will be continually probed for vulnerabilities. Self-hosting will probably work great for a protocol like Pond, where there are strict restrictions on who may deliver incoming messages. Email, however, is a protocol that is wide open and prone to abuse. +* **Servers are on a hostile network**: Because a server needs to have open ports that are publicly accessible from the internet at all times, running one is much trickier than a simple desktop computer. It is much more critical to make sure security upgrades are applied in a timely manner, and that you are able to respond to external attacks, such as "Spam Bombs". Any publicly addressable IP that is put on the open internet will be continually probed for vulnerabilities. Email is a protocol that is wide open and prone to abuse. * **Sysadmins are not robots**: No one has yet figured out how to make self-healing servers that don't require a skilled sysadmin to keep them healthy. Once someone does, a lot of sysadmins will be out of work, but they are presently not very worried. There are many things that commonly go wrong with servers, such as upgrades failing, drives filling up, daemons crashing, memory leaks, hardware failures, and so on. * **Does not address the important problems**: Moving the physical location of a device does nothing to solve the hard problems associated with easy-to-use email security (such as data availability and key validation). Some of the approaches to these problems rely on service provider infrastructure that would be infeasible to self host. * **DNS is hard**: One of the important security problems with traditional email is the vulnerability MX DNS records. Doing DNS correctly is hard, and not something that can be expected of the common user. -Self-hosted email is an intriguing "legal hack", albeit one that faces many technical challenges. +All of the above problems however do not apply for public-key routing mail systems such as secushare, Retroshare, Briar, I2PBote and Pond. The latter actually needs a server to function, so a self-hosted home server is very recommendable. The others can be operated from all kinds of devices including home server boxes. Dark Mail Alliance ----------------------------------------------------------- @@ -304,6 +351,21 @@ From its early conception, part of FreedomBox was "email and telecommunications Although Mailpile is primarily a mail client, the background Python component can read the Maildir format for email. This means you could install Mailpile on your own server running a Mail Transfer Agent (MTA) like postfix or qmail. You would then access your mail remotely by connecting to your server via a web browser. +Mail-in-a-box +----------------------------------------------------------- + +github.com/JoshData/mailinabox + +Mail-in-a-box helps people set up self-hosted email for linux hobbyists and email developers. It will install and configure the necessary Debian packages required to turn a machine running Ubuntu into a self-hosted email server. It provides a fairly straightforward, standard email server with IMAP, SMTP, greylisting, DKIM and SPF. It also includes a command line tool for adding and removing accounts. + +**Advantages:** Something quick for anyone with some linux skill who wants to experiment with email. + +**Limitations:** Setting up an email server is the easy part, maintaining the service over time is the tricky part. Without any automation recipes using something like Puppet, Chef, Salt, or CFEngine, mail-in-a-box is unlikely to be useful to anyone but the curious hobbyist. + +* Written in: Bash +* Source code: https://github.com/JoshData/mailinabox +* License: CC0 1.0 Universal + kinko ----------------------------------------------------------- @@ -333,11 +395,11 @@ per [olimex](https://www.olimex.com/wiki/A10-OLinuXino-LIME). The "infrastructure" projects give a service provider the opportunity to offer secure email accounts to end-users. By modifying how both email clients and email servers work, these projects have the potential to deploy greater security measures than are possible with a client-only approach. For example: -* Encrypted relay: A secure email provider is able to support, and enforce, encrypted transport when relaying mail to other providers. This is an important mechanism for preventing mass surveillance of metadata (which is otherwise not protected by OpenPGP client-side encryption of message contents). +* Encrypted relay: A secure email provider is able to support, and enforce, encrypted transport when relaying mail to other providers. This is a mechanism for reducing likelihood of surveillance of metadata (which is otherwise not protected by OpenPGP client-side encryption of message contents), if the counterparts of your communication aren't using offerings affected by the PRISM surveillance program, possibly including cheap VPS hosted servers. * Easier key management: A secure email provider can endorse the public keys of its users, and provide assistance to various schemes for automatic validation. Additionally, a secure email provider, coupled with a custom client, can make it easy to securely manage and back up the essential private keys which are otherwise cumbersome for most users to manage. -* Invisible upgrade to better protocols: A secure email provider has the potential to support multiple protocols bound to a single user@domain address, allowing automatic and invisible upgrades to more secure post-email protocols when both parties detect the capability. -* A return to federation: The recent concentration of email to a few giant providers greatly reduces the health and resiliency of email as an open protocol, since now only a few players essentially monopolize the medium. Projects that seek to make it easier to offer secure email as a service have the potential to reverse this trend. -* Secure DNS: A secure provider can support DNSSEC and DANE, while most other email providers are unlikely to anytime soon. This is very important, because it is easy to hijack the MX records of a domain without DNSSEC. +* Invisible upgrade to better protocols: A secure email provider has the potential to support multiple protocols bound to a single user, allowing automatic and invisible upgrades to more secure post-email protocols when both parties detect the capability. +* A hope for federation: The recent concentration of email to a few giant providers greatly reduces the health and resiliency of email as an open protocol, since now only a few players essentially monopolize the medium. Projects that seek to make it easier to offer secure email as a service have the potential to reverse this trend. +* Better DNS: A secure provider can support DNSSEC and DANE, while most other email providers are unlikely to anytime soon. This is important, if you really insist on using traditional email, because it is easy to hijack the MX records of a domain without DNSSEC. * Minimal data retention: A service provider that follows "best practices" will choose to retain less personally identifiable information on their users, such as their home IP addresses. The goal of both projects in this category is to build systems where the service provider is untrusted and cannot compromise the security of its users. @@ -346,6 +408,7 @@ Despite the potential of this approach, there are several unknown factors that m * In order to benefit from a more secure provider, a user will need to switch their email account and email address, a very high barrier to adoption. * Where once there were many ISPs that offered email service, it is no longer clear if there is either the demand to sustain many email providers or the supply of providers interested in offering email as a service. +* Given that more radical new mail systems solve all of the above problems, it may be a waste of time to stick to the old traditions. * Users must download and install a custom application. Dark Mail Alliance @@ -385,118 +448,175 @@ LEAP includes both a client application and turn-key system to automate the proc **Application:** The client application works with any existing MUA by exposing a local IMAP/SMTP server that the MUA can connect to. There is a Thunderbird extension to automate configuration of the account in Thunderbird. The client application communicates with the service provider using a custom protocol for synchronizing encrypted databases. The application is a very small C program that launches the Python code. The user interface is written using Qt. -**Limitations:** In the current implementation, security properties of forward secrecy and metadata production are not end-to-end. Instead, the client relies on the service provider to ensure these properties. This limitation is due to some inherent limitations in the existing protocols for secure email. As with many of the other projects, LEAP's plan is to invisibly upgrade to a post-email protocol when possible in order to overcome these limitations. +**Limitations:** In the current implementation, security properties of forward secrecy and metadata protection are not end-to-end. Instead, the client relies on the service provider to ensure these properties. This limitation is due to some inherent limitations in the existing protocols for secure email. As with many of the other projects, LEAP's plan is to invisibly upgrade to a post-email protocol when possible in order to overcome these limitations. * Written in: Python * Source code: https://leap.se/source * Design documentation: https://leap.se/docs * License: mostly GPL v3, some MIT and AGPL. -Post-email alternatives +Public-Key Routing Systems =========================================================== -There are several projects to create alternatives to email that are more secure yet still email-like. - -These projects share some common advantages: +Out of a tradition of peer-to-peer systems a new breed of Internet routing technologies is emerging which has quite interesting effects regarding possible solutions for email. +These technologies share some essential advantages: +1. **Public key as the identifier:** All of these projects use the user's public key as the unique routing identifier for a user, allowing for decentralized and unique names. This neatly solves the problem of validating public keys, because every identifier *is* the key, so there is no need to establish a mapping. +1. **Ease of use:** By having the cryptography an essential part of how the Internet works, applications hardly need to deal with it any longer. All communication is always encrypted to the recipients of the messages, allowing for dramatically simplified user interfaces that anyone can learn to use. +1. **Impossible to use without encryption:** Some researchers think the most awful problem about traditional email is that as long as it can accept unencrypted mail, people will send unencrypted mail and expose most private aspects of the recipient's life against her will. Public-key based routing systems make such profoundly human behaviour impossible and thus close the biggest of all loopholes in Internet technology. +1. **No account management:** Since public-key routing leads communications directly to the receiving endpoints, there is no need for any account registration on any servers. A business card containing your first contact's public key is sufficient to bootstrap your node and start using the new system. You just hold it in front of the webcam to access her profile, start a contact subscription or formulate a message. 1. **Trust no one:** These projects share an approach that treats the network, and all parties on the network, as potentially hostile and not to be trusted. With this approach, a user's security can only be betrayed if their own device is compromised or the software is flawed or tampered with, but the user is protected from attacks against any service provider (because there typically is not one). -1. **Fingerprint as identifier:** All these projects also use the fingerprint of the user's public key as the unique routing identifier for a user, allowing for decentralized and unique names. This neatly solves the problem of validating public keys, because every identifier basically *is* a key, so there is no need to establish a mapping from an identifier to a key. +1. **No authorities:** Since the cryptographic operations are self-validating, there is no need for neither certification nor domain naming authorities. The bureaucracy of having an identity on the Internet is gone. +1. **Potential for mesh networking:** If implemented properly, public-key based routing systems do not depend on the Internet's current routing methodology such as BGP, the Border Gateway Protocol. This means they can self-organize even if there was no IP-based routing underneath. These technologies can be deployed as an overlay over the existing Internet, but they can also find routes across a network of mesh nodes or an alternative Internet which models intercontinental underwater cabling as an unusually strong direct link between nodes that are actually very distant from each other. Many of these new tools have the ability to route by bluetooth or ad-hoc wireless proximity, allowing for independent email infrastructure in countries where the government has to be considered an opponent. -Except for Pond, all these alternatives take a pure peer-to-peer approach. As such, they face particular challenges: +Disadvantages are: -1. **The "Natural" Network**: Many advocates of peer-to-peer networking advance the notion that decentralized networks are the most efficient networks and are found everywhere in nature (in the neurons in our brain, in how mold grows, in how insects communicate, etc). This notion is only partially true. Networks are found in nature, but these network are not radically decentralized. Instead, natural networks tend to follow a power law distribution (aka "[scale free networks](https://en.wikipedia.org/wiki/Scale-free_network)"), where there is a high degree of partial centralization that balances "brokerage" (ability to communicate far in the network) with "closure" (ability to communicate close in the network). Thus, in practice, digital networks rely on "super hubs" that process most of the traffic. These hubs need to be maintained and hosted by someone, often at great expense (and making the network much more vulnerable to Sybil attacks). -1. **The Internet:** Sadly, the physical internet infrastructure is actually very polycentric rather than decentralized (more akin to a tree than a spider's web). One reason for the rise of cloud computing is that resources are much cheaper near the core of the internet than near the periphery. Technical strategies that attempt to leverage the periphery will always be disadvantaged from an efficiency standpoint. -1. **Traffic Analysis:** Most of the peer-to-peer approaches directly relay messages from sender's device to recipient's device, or route messages through the participant's contacts. Such an approach to message routing makes it potentially very easy for a network observer to map the network of associations, even if the message protocol otherwise offers very strong metadata protection. -1. **Sybil Attacks:** By their nature, peer-to-peer networks do not have a method of blocking participation in the network. This makes them potentially very vulnerable to [Sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack), where an attacker creates a very large number of fake participants in order to control the network or reveal the identity of other network participants. -1. **Mobile:** Peer-to-peer networks are resource intensive, typically with every node in the network responsible for continually relaying traffic and keeping the network healthy. Unfortunately, this kind of thing is murder on the battery life of a mobile device, and requires a lot of extra network traffic. -1. **Identifiers**: Using key fingerprints as unique identifiers has some advantages, but it also makes user identifiers impossible to remember. There is a lot of utility in the convenience of memorable username handles, as evidence in the use of email addresses and twitter handles. -1. **Data Availability**: Unless also paired with a cloud component, peer-to-peer networks have much lower data availability than other approaches. For example, it takes much longer to update message deliveries from a peer network than from a server, particularly when the device has been offline for a while. Also, if a device is lost or destroyed, generally the user loses all their data. +1. You need to install custom new technology. +1. Several projects still have some specific drawbacks due to their youth. +1. Allowing for communication and data exchange even if sender and recipient aren't on the network at the same time takes special provisions in relay infrastructure that isn't yet implemented in any of the projects. This problem does not persist if at least one of the participants in a communication is always on (think of a smartphone flatrate or a router device at home). +1. To ensure safety in cryptographic communication it is required that you set up contacts in advance before you can communicate with them. This is a strength, but it may appear as a disadvantage at first. -Most of these challenges have possible technological solutions that might make peer-to-peer approaches the most attractive option in the long run. For example, researchers may discover ways to make p2p networks less battery intensive. For this reason, it is important that research continue in this area. However, [in the long run we are all dead](https://en.wikiquote.org/wiki/John_Maynard_Keynes) and peer-to-peer approaches face serious hurdles before they can achieve the kind of user experience demanded today. +When in their infancy, these projects usually start out with a pure peer-to-peer architecture, which has the drawbacks of being slow, CPU intensive and potentially less protective of the social graph than even a federated architecture. Projects that have come of age such as Tor and I2P however demonstrate how an infrastructure of collaborating relay nodes can provide for performance, metadata protection and avoid computational load on the endpoints. Strategies for organization of such relay infrastructure have been a hot topic of research for over a decade. Most of these infrastructures make use of distributed hashtable technology, which in its infancy was suffering of problems like lack of look-up privacy and [Sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack). The research community has provided for viable strategies to solve these problems using reputation systems based on behavior or social graph and projects such as GNUnet and Tribler have implemented them. -Bitmessage ------------------------------------------------------------ +It is important to understand that the way these new systems do not allow for traditional user@domain addressing is not a drawback, it is a strength since users are no longer required to possess a keyboard or even know how to read and write. It is true that you do not realistically want to add a contact by typing in their public key information. What you do is to use the methods described in Key Discovery. -[Bitmessage](https://bitmessage.org) - -Bitmessage is a peer-to-peer email-like communication protocol. It is totally decentralized and places no trust on any organization for services or validation. - -Advantages: - -* resistant to metadata analysis -* relatively easy to use -* works and is actively used by many people. +Briar +----------------------------------------------------------- -Disadvantages: - -* no forward secrecy -* unsolved scaling issues: all messages are broadcast to everyone -* because there is no forward secrecy, it is especially problematic that anyone can grab an encrypted copy of any message in the system. This means if the private key is ever compromised, then all the past messages can be decrypted easily by anyone using the system. -* relies on proof of work for spam prevention, which is probably not actually that preventative (spammers often steal CPU anyway). +[Briar](http://briar.sourceforge.net) is a project working on a messaging and forum solution which distributes content opportunistically, that means whenever two nodes meet. It is designed to support the work of activists in oppressive countries by making use of wireless mesh networking between telephony devices. Briar actually doesn't use public keys for identification of users, each communication thread has its own ephemeral key which is advanced for each message, achieving an improved kind of forward secrecy similar to Pond's. Cables ----------------------------------------------------------- -https://github.com/mkdesu/cables +[Cables](http://dee.su/cables) is a mail system that runs over both Tor and I2P. It uses their respective public-key routing capabilities by generating a .onion and a .i2p service on each. The system periodically tries to contact recipients in order to deliver mail, which limits its scalability. Both communication partners have to be online for delivery to succeed. Regular mail clients can be used for composition and consumption of messages. * Written in: C, Bash * License: GPL v2 -Dark Mail Alliance +cjdns and net2o ----------------------------------------------------------- -The Dark Mail Alliance plans to incorporate traditional email, a federated email alternative, and a second email alternative that is pure peer-to-peer. Details are not yet forthwith. +[cjdns](http://cjdns.info) and [net2o](http://net2o.de) are public-key routing overlay networks for the Internet. They do not provide any custom email applications, so you have to combine them with running an email server on your personal device. They provide encryption for any kind of communication by default, but they do not deliver transaction data protection. Again, if both nodes are alternatingly offline, mails will remain stuck in the queue. FlowingMail ----------------------------------------------------------- -[FlowingMail](http://flowingmail.com) +[FlowingMail](http://flowingmail.com) is a DHT-based cryptographically routed email system in the planning stage. UDP is used to put mails into the DHT. Problem: How does the DHT know it is not being spammed? -P2P secure, encrypted email system. +Freemail +----------------------------------------------------------- + +[Freemail](https://freenetproject.org/freemail.html) is an email system for Freenet. It emulates traditional IMAP and SMTP so you can use your regular mail software with it. The addressing then appears as @.freemail Goldbug ----------------------------------------------------------- -http://goldbug.sf.net +[Goldbug](http://goldbug.sf.net) runs on an opportunistic broadcast routing mechanism called "Echo," but it currently offers no transaction data protection. * Written in: C++, Qt * License: BSD -Pond +I2P-Bote ----------------------------------------------------------- -[pond.imperialviolet.org](https://pond.imperialviolet.org/) +[I2P-Bote](http://i2pbote.i2p.us) is a messaging system on top of I2P. It has the appearance of a web mail interface but actually runs on the local host of the owner and makes use of I2P's transaction data obfuscation capabilities embedded in its public-key based routing. Messages are directly stored into a DHT and kept for several months until the recipient picks them up. + +* Written in: Java +* License: GPLv3 + +Pond +----------------------------------------------------------- -Pond is an email-like messaging application with several unique architectural and cryptographic features that make it stand out in the field. +[Pond](https://pond.imperialviolet.org) is an email-like messaging application with several unique architectural and cryptographic features that make it stand out in the field. -**Message Encryption**: Pond uses [Axolotl](https://github.com/trevp/axolotl/wiki) for asynchronous forward secret messages where the key is frequently ratcheted (akin to OTR, but more robust). +**Message Encryption**: Similarly to Briar, Pond uses [Axolotl](https://github.com/trevp/axolotl/wiki) for asynchronous forward secret messages where the key is frequently ratcheted (akin to OTR, but more robust). -**Routing**: Pond uses a unique architecture where every user relies on a service provider for receiving messages, but sent messages are delivered directly to the recipient's server (over Tor). This allows for strong metadata protection, but does not suffer from the other problems that peer-to-peer systems typically do. In order to prevent excessive Spam under this scheme, Pond uses a clever system of group signatures to allow the server to check if a sender is authorized to deliver to a particular user without leaking any information to the server. +**Routing**: Pond uses a unique architecture where every user relies on a service provider for receiving messages, but sent messages are delivered directly to the recipient's server using Tor's public-key routing capability better known as "hidden services." Transaction data protection is given not only by using Tor, but also in the way periodic meaningless transactions are performed. In order to prevent Spam under this scheme, Pond uses a clever system of group signatures to allow the server to check if a sender is authorized to deliver to a particular user without leaking any information to the server. -**Keys**: Pond uses Panda, a system for secure peer validation using short authentication strings. +**Keys**: Pond uses PANDA, a method for secure peer discovery and validation using short authentication strings. This has the advantage of not appearing bureaucratic as shared secret exchanges on OTR do, since this method actually establishes the first contact. On the other hand it has the disadvantage of currently operating on a centralized service. Pond's advantages include: -* Very high security: forward secrecy, metadata protection, resistant to traffic analysis. -* Pond hybrid federated and peer-to-peer approach is cool and holds a lot of promise. +* Very high security: forward secrecy, metadata protection, resistance to traffic analysis. +* Pond hybrid federated and public-key routing approach is a reasonable interim solution until public-key routing provide for message availability themselves. * Written in Go, and thus probably has many fewer security flaws than programs written in C or C++. * Pond is written by Adam Langley, an extremely well respected crypto-engineer. +* The usability of Pond is imperfect, but already superior to most PGP interfaces. Pond's disadvantages include: -* Uses non-human memorial unique identifiers, although this is not a necessary element of the design. -* Requires that you set up contacts in advance before you can communicate with them (via a Short Authentication String or full public key exchange). -* Pond is still very difficult to install and use. +* It maintains the old-fashioned dependency on servers, and since maintaining a Pond server is rather unusual, the architecture is prone to generating few very popular servers which then constitute honeypots and single points of failure. +* Pond is not architected for group communications and would scale worse than regular email at that. +* Pond's architecture does not allow to evolve into instant messaging or social networking, instead it imposes a deceleration of human interactions which can be considered a strength in the eyes of the 'slow tech' community. Some say the name stems from the time it gives you to ponder about what you will write. +* It does not provide support for generation or acquisition of QR codes, yet. +* Pond is currently rather difficult to install. -Pond is an exciting experiment in how you could build a very secure post-email protocol. Although Pond currently uses non-human identifiers, Pond could be easily modified to use traditional email username@domain.org identifiers (because it relies on service providers for message reception). The requirement in Pond that both parties pre-exchange keys could also be modified to allow users to set up addresses that could receive messages from anyone, albeit at the cost of likely Spam. Currently, Pond uses Tor to anonymize message routing, but the Tor network was designed for low-latency. Pond could potentially use a more secure anonymization network that was designed for higher-latency asynchronous messages. - -Ultimately, Pond's unique design makes it a very strong candidate for incorporation into a messaging application that could automatically upgrade from email to Pond should it detect that both parties support it. +Pond is an exciting experiment in how you could build a very secure post-email protocol. Currently, Pond uses Tor to anonymize message routing, but the Tor network was designed for low-latency. Pond could potentially use a more secure anonymization network that was designed for higher-latency asynchronous messages. * Written in: Go * Source code: https://github.com/agl/pond * License: BSD * Platforms: anything you can compile Go on (for command line interface) or anything you can compile Go + Gtk (for GUI interface). +Retroshare +----------------------------------------------------------- + +[Retroshare](http://retroshare.sourceforge.net) is a complex and somewhat confusing application that provides forums, subscription channels, file sharing, chats and a mail interface that looks very familiar to traditional email users. In practice it is an impressive one stop shop for peer-to-peer group collaboration where everything is end-to-end encrypted and forward secret where applicable. + +Retroshare has no relay network, so it operates its own distributed hashtable from each node. This means it has the typical deficits of P2P technology: slow and continously making use of power and bandwidth. It also deficits in metadata protection since nodes typically interact directly with other nodes, thus exposing the social graph. All of these problems can be solved by combining Retroshare with a Tor hidden service. In that case the built-in DHT is disabled and Retroshare operates on top of Tor's public-key routing infrastructure. This set-up has been done before, but it isn't documented. Retroshare developers have promised to support it officially. + +One annoying bug still persists: When connecting a Retroshare node using the TLS protocol, a certificate is returned that exposes the user name provided by its user. This means you should always use a pseudonym you have never used in any other context before to avoid getting socially graphed. + +secushare +----------------------------------------------------------- + +[Secure Share](http://secushare.org) has been cited in a research paper as the most advanced and ambitious of projects aimed at providing a distributed social network, which naturally includes a mail system. secushare is architected on top of a publish/subscribe paradigm, which hides the complexity of multicast data store and forward distribution trees operating within the [GNUnet](https://gnunet.org) public-key routing framework. This means, that if everything goes well, resulting applications will have the scalability properties of cloud technology although they are actually operating on voluntarily contributed infrastructure. + +The aim is to offer a large number of Facebook-like social functionality in a distributed manner, letting each endpoint have a view of its neighboring social graph while hosting profile and microblogging data. This data is then used to 1. impede sybil attacks as described in several research papers, to 2. allow for social adoption of contacts, freeing the majority of users from the hassle with public key crypto, and 3. it could possibly help in the improvement of quality of obfuscation circuit construction, as also suggested by some research work. The integration of mail and social networking is therefore not only natural from a usability perspective, it also makes sense from a security standpoint. + +The built-in mail system integrates synchronous and group messaging into a single "channel" concept. Encryption happens automatically using ephemeral ratchets for each pubsub channel. Channels can contain an unlimited number of recipients, but they can be as small as two people or just two devices of the same person, allowing for synchronization. Data availability is achieved by having relay nodes store messages until they can be delivered. Relay nodes are chosen in a strategically unpredictable manner akin to Tor's EntryNodes so that honeypots and single points of failure are avoided. A more flexible kind of onion routing is planned for transaction data protection, allowing the user to choose a trade-off between privacy and convenience themselves. But even if they choose convenience, they will experience better protection than what they get from email today, and they will provide cover traffic to those in need of better privacy. + +GNUnet supports secushare with fully Internet-independent routing, capable of running over custom infrastructure and mesh networks, and a highly innovative look-up-privacy-protecting cryptographic name resolution mechanism on top of hardened DHT technology, called GNS. secushare uses PSYC as its higher level social messaging protocol syntax, drawing from experience in efficient and extensible design of decentralized communication systems. + +The big problem with secushare is that since its prototype in 2012 the code has been dismantled and is being reconstructed within the framework of GNUnet, so it's currently not available. The prototype was done in form of a native Qt/QML application, but a Javascript API for web-based UIs is also in the planning. Another issue is that GNUnet does not provide onion routing or other method of obfuscation as yet, and that a back-end of relay nodes similar to Tor's isn't available yet - thus, running GNUnet currently necessitates more local resources than it should. + +* Written in: C +* Source code: https://gnunet.org/svn/gnunet/src/ +* License: Affero GPL +* Platforms: anything + +Unclassified +=========================================================== + +These projects use unusual approaches or haven't been categorized by the authors properly yet. + +Bitmessage +----------------------------------------------------------- + +[Bitmessage](https://bitmessage.org) is a peer-to-peer email-like communication protocol. It is totally decentralized and places no trust on any organization for services or validation. + +Advantages: + +* resistant to metadata analysis +* relatively easy to use +* works and is actively used by many people. + +Disadvantages: + +* unsolved scaling issues: all messages are broadcast to everyone +* no forward secrecy +* because there is no forward secrecy, it is especially problematic that anyone can grab an encrypted copy of any message in the system. This means if the private key is ever compromised, then all the past messages can be decrypted easily by anyone using the system. +* relies on proof of work for spam prevention, which is probably not actually that preventative (spammers often steal CPU anyway). + +Dark Mail Alliance +----------------------------------------------------------- + +The Dark Mail Alliance plans to incorporate traditional email, a federated email alternative, and a second email alternative that is pure peer-to-peer. Details are not yet forthwith. + +Susimail +----------------------------------------------------------- +[Susimail](http://echelon.i2p.us/I2Pguide/susimail.html) is a web-based mail client for I2P's centralized but anonymized mail service running at mail.i2p. + Related Works =========================================================== @@ -506,3 +626,10 @@ There are many technologies that don't belong in this document because they eith * [OpenCom](http://opencom.io) is a secure email and email-like communication in the planning stages. * [Ubiquitous Encrypted Email](https://github.com/tomrittervg/uee) is a protocol draft for standards that could lead to universal adoption of encrypted email. * [Redecentralize](https://github.com/redecentralize/alternative-internet) has a list of decentralized networks, such as Tor. +* [#youbroketheinternet](http://youbroketheinternet.org) is a platform that explains and promotes public-key based routing technologies for a new Internet (usually spelled GNU for its strict political requirements) and organizes them on an architectural map. It has dozens of videos from the project presentations held at events it hosts, explaining the various projects in detail. You should particularly appreciate the one with Jacob Appelbaum presenting Pond. + +Credits +=========================================================== + +The [original version](https://github.com/OpenTechFund/secure-email) of this document was authored by the lead developer of LEAP, who unfortunately [has some biased views](https://github.com/OpenTechFund/secure-email/pull/10) on the topic, so he prefers to maintain his own version of this. You can [inspect the changes](https://github.com/symlynX/secure-email/compare/OpenTechFund:master...master) from one version to the other. +