New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrote the paragraphs on public-key routing, added several projects and improved the overall accuracy of assertions #10

Open
wants to merge 22 commits into
base: master
from
Commits
Jump to file or symbol
Failed to load files and symbols.
+6 −6
Diff settings

Always

Just for now

Viewing a subset of changes. View all

Metadata Protection: removed a lot of bias and added competence conce…

…rning public-key based routing systems
  • Loading branch information...
carlo von lynX
carlo von lynX committed Apr 25, 2014
commit 6d3ff87749f1e7e72d29d67eb290f5944425d4a9
View
@@ -55,19 +55,19 @@ This is where we are now: we have public key technology that is excessively diff
* 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. Newer strategies for discovery are the exchange of public keys 1. using QR codes printed on business cards or brochures, 2. by bringing end devices into bluetooth range to each other, 3. by adopting new people from a trusted person's social graph.
* 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. 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. Systems that route by public key don't run into this problem, since there is no distinction between a person and her public key.
* 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 memory. This way the master key can issue revocations for derived keys and bring new ones in circulation.
<a name="metadata-protection"></a>Metadata Protection
<a name="metadata-protection"></a>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 public-key based routing face the prospect of increasing Spam, since one of the primary methods used to prevent Spam is analysis of metadata.
<a name="forward-secrecy"></a>Forward Secrecy
-----------------------------------------------------------
ProTip! Use n and p to navigate between commits in a pull request.