1 files changed, 15 insertions, 9 deletions

diff --git a/pages/services/technology/routing/en.haml b/pages/services/technology/routing/en.haml
index 35d52ed..9ea5671 100644
--- a/pages/services/technology/routing/en.haml
+++ b/pages/services/technology/routing/en.haml
@@ -4,12 +4,10 @@
 
 %p Unfortunately, existing technologies for secure routing, such as StartTLS for email or chat, are insufficient in today's environment and easily thwarted. StartTLS also does little to protect a service provider from being required to keep association records of its users.
 
-%h1 Map resistant routing
+%h1 Graph Resistant Routing (Grr!)
 
 %p One of the major goals of LEAP is to make message routing that is resistant to social graph mapping.
 
--# The LEAP design includes an improved method of encrypted transport negotiation and an system for aliased message routing to protect the social graph from even the service providers themselves.
-
 %p How would this work? Imagine users Alice and Bob. Alice wants to correspond with Bob but doesn't want either her service provider or Bob's service provider to be able to record the association. She also doesn't want a network observer to be able to map the association.
 
 %p When Alice first sends a message to Bob, Alice's client will initiate the following chain of events on her behalf, automatically and behind the scenes.
@@ -23,16 +21,19 @@
   %li Alice's client receives this alias, and records the mapping between Bob's public address and his private alias.
   %li Alice's client then relays the original message to Bob's alias.
 
-Subsequently, whenever Alice or Bob want to communicate, they use the normal public addresses for one another, but behind the scenes their clients will rewrite the source and recipient of the messages to use the private aliases.
+%p Subsequently, whenever Alice or Bob want to communicate, they use the normal public addresses for one another, but behind the scenes their clients will rewrite the source and recipient of the messages to use the private aliases.
 
-This scheme is backwards compatible with existing messaging protocols, such as SMTP and XMPP.
+%p This scheme is backwards compatible with existing messaging protocols, such as SMTP and XMPP.
 
 %h1 Limitations
 
-%p There are four major limitations to this scheme:
+%p There are five major limitations to this scheme:
 
 %ol
   %li
+    %b Alias unmasking attacks:
+    because each service provider maintains an alias map for their own users, an attacker who has gained access to this alias map can de-anonymize all the associations into and out of that particular provider, for the past and future.
+  %li
     %b Timing attacks:
     a statistical analysis of the time that messages of a particular size are sent, received, and relayed by both service providers could reveal the map of associations.
   %li
@@ -45,8 +46,13 @@ This scheme is backwards compatible with existing messaging protocols, such as S
     %b Client problem:
     if the user's device is compromised, the record of their actual associations can be discovered.
 
-%p At this point, we feel that it is OK to live with these limitations in order to be backward compatible with existing messaging protocols. The first two attacks are only possible by a very powerful adversary. One so powerful that association mapping is probably the least of your worries.
+%p At this point, we feel that it is OK to live with these limitations for the time being in order to simply the logic of the user's client application and to ensure backward compatibility with existing messaging protocols.
 
-%p This scheme is designed to prevent the casual, mass surveillance of all communication that currently takes place in repressive and democratic countries alike, by both governments and corporations. It greatly reduces the capacity for association mapping of both traffic over the wire and in stored communication. It is not designed to make a particular user anonymous in the face of a powerful adversary.
+%p Possible future enhancements could greatly mitigate these attacks:
+
+%ol
+  %li We could use temporarily aliases that rotate daily, perhaps based on an HMAC counter, based on a shared secret between two users.
+  %li The 'alias service' could be run by a third party, so that associations within a single provider are also resistant to mapping.
+  %li A service provider with sufficient traffic could be in a very good position to be able to aggregate and time-shift the messages it relays in order to disrupt timing attacks.
 
-%p However, a service provider using this scheme that has sufficient traffic will be in a very good position to be able to aggregate and time-shift the messages it relays in order to disrupt timing attacks—once researchers have a better understanding of how to effectively counter timing attacks.
\ No newline at end of file
+%p Ultimately, however, most of these attacks are a problem when faced with an extremely powerful adversary. This scheme is not designed for these situations. Instead, it is designed to prevent the casual, mass surveillance of all communication that currently takes place in repressive and democratic countries alike, by both governments and corporations. It greatly reduces the capacity for association mapping of both traffic over the wire and in stored communication. It is not designed to make a particular user anonymous in the face of a powerful adversary.