From e6108f67158b082fd9a98346900450c45fb0aea7 Mon Sep 17 00:00:00 2001 From: jrandom Date: Mon, 19 Jul 2004 16:00:26 +0000 Subject: [PATCH] cleaned up links and html --- pages/how_garlicrouting.html | 23 ++++++++-------- pages/how_intro.html | 45 +++++++++++++++---------------- pages/how_networkcomparisons.html | 44 +++++++++++++++--------------- pages/how_networkdatabase.html | 3 ++- pages/how_tunnelrouting.html | 40 +++++++++++++++------------ 5 files changed, 80 insertions(+), 75 deletions(-) diff --git a/pages/how_garlicrouting.html b/pages/how_garlicrouting.html index 17c90bcc..16d054f0 100644 --- a/pages/how_garlicrouting.html +++ b/pages/how_garlicrouting.html @@ -1,9 +1,9 @@

-As briefly explained on the I2P/Overview, in addition to sending -messages through tunnels (via I2P/Tunnel), I2P uses a technique called +As briefly explained on the intro, in addition to sending +messages through tunnels (via tunnels), I2P uses a technique called "garlic routing" - layered encryption of messages, passing through routers selected by the original sender. This is similar to the way Mixmaster -(see I2P/OtherEfforts) sends messages - taking a message, encrypting it +(see network comparisons) sends messages - taking a message, encrypting it to the recipient's public key, taking that encrypted message and encrypting it (along with instructions specifying the next hop), and then taking that resulting encrypted message and so on, until it has one layer of encryption @@ -12,7 +12,7 @@ and I2P's garlic routing is that at each layer, any number of messages can be contained, instead of just a single message.

- +

In addition to the cloves, each unwrapped garlic message contains a sender specified amount of padding data, allowing the sender to take active countermeasures @@ -24,21 +24,22 @@ against traffic analysis. I2P uses garlic routing in three places:

-There are also significant ways that this technique can be used to improve the performance of the network, exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability. +There are also significant ways that this technique can be used to improve the performance of the network, +exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability.

Encryption

-The encryption of each layer in the garlic message uses the ElGamal?/AES+SessionTag? algorithm -(as outlined at I2P/ElGamalAESSessionTag), which avoids the cost of a full 2048bit ElGamal? - -encryption for subsequent messages (using instead a random previously specified SessionTag? plus -256bit AES encryption). +The encryption of each layer in the garlic message uses the ElGamal/AES+SessionTag algorithm, +which avoids the cost of a full 2048bit ElGamal encryption for subsequent messages (using instead a random previously +specified SessionTag plus 256bit AES encryption).

References

diff --git a/pages/how_intro.html b/pages/how_intro.html index f84b9074..b2196f77 100644 --- a/pages/how_intro.html +++ b/pages/how_intro.html @@ -19,14 +19,14 @@ or even taken over to attempt more malicious attacks.

where messages are addressed to cryptographic keys (Destinations) and can be significantly larger than IP packets. Some example uses of the network include "eepsites" (webservers hosting normal web applications within I2P), a BitTorrent port ("I2PSnark"), -or a distributed data store. With the help of mihi's I2PTunnel application, +or a distributed data store. With the help of mihi's I2PTunnel application, we are able to stream traditional TCP/IP applications over I2P, such as SSH, irc, a squid proxy, and even streaming audio. Most people will not use I2P directly, or even need to know they're using it. Instead their view will be of one of the I2P enabled applications, or perhaps as a little controller app to turn on and off various proxies to enable the anonymizing functionality.

An essential part of designing, developing, and testing an anonymizing network is to define the -threat model, since there is no such thing as "true" anonymity, just +threat model, since there is no such thing as "true" anonymity, just increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to communicate in arbitrarily hostile environments by providing militant grade anonymity, mixed in with sufficient cover traffic provided by the activity of people who require less anonymity. This includes letting Joe Sixpack @@ -36,46 +36,45 @@ corporations cannot identify her, as well as Will Whistleblower to publish sensi others.

Why?

-

There are a multitude of fantastic reasons why we need a system to support +

There are a multitude of fantastic reasons why we need a system to support anonymous communication, and everyone has their own personal rationale. There have are many -other efforts working on finding ways to provide varying degrees of +other efforts working on finding ways to provide varying degrees of anonymity to people through the Internet, but we could not find any that met our needs or threat model.

How?

-

The network at a glance is made up of a set of nodes (“routers”) with a number of unidirectional -inbound and outbound virtual paths ("tunnels", as outlined on Tunnel Routing). +

The network at a glance is made up of a set of nodes ("routers") with a number of unidirectional +inbound and outbound virtual paths ("tunnels", as outlined on the tunnel routing page). Each router is identified by a cryptographic RouterIdentity which is typically long lived. These routers communicate with each other through existing transport mechanisms (e.g. TCP, UDP, PHTTP), passing various messages. Client applications have their own cryptographic identifier ("Destination") which enables it to send and receive messages. These clients can connect to any router and authorize the temporary allocation ("lease") of some tunnels that will be used for sending and receiving messages through the -network. I2P has its own internal network database (using a modification of +network. I2P has its own internal network database (using a modification of the Kademlia algorithm) for distributing routing and contact information.

The following illustration is a simplistic view regarding how tunnels, routers, and destinations are associated, with a pair of inbound tunnels (pink lines) leading towards the router which the destination is connected to (little "a"), with a set of outbound tunnels (green lines) leading away from that router. The gateway for each of the inbound tunnels (big "A"s) are identified in the lease -as published in the network database. Additional topological information can be found -here.

+as published in the network database.

-

The network topology

+

The network topology

Messages send from one Destination to another are (typically) sent through a pair of tunnels - first they go out one of the local router's outbound tunnels with instructions specifying that the outbound tunnel's end point forward the message to one of the target Destination's inbound tunnel gateways, which, on receiving the message, passes it down the tunnel to the recipient. Various mechanisms are -used to secure these tunnel routed messages, as described tunnel routing. +used to secure these tunnel routed messages, as described tunnel routing. In addition, they can be sent in parallel down multiple tunnels, with the last router discarding duplicates.

-

I2P Tunnel sending

+

I2P Tunnel sending

Some of the messages sent in the network (such as those used to manage tunnels, publish some Leases, and deliver long lived end to end messages) may be instead are sent via -garlic routing. Inspired by a subsection for future works written by +garlic routing. Inspired by a subsection for future works written by Michael Freedman within Roger Dingledine's freehaven thesis, and with some similarities to onion routing. I2P's garlic routing allows multiple messages @@ -86,12 +85,12 @@ determine how many cloves are contained as well as how those cloves should be pr hence there are no directory servers keeping statistics regarding the performance and reliability of routers within the network. As such, each router must keep and maintain profiles of various routers and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability -needs of the users, as described in the peer selection pages

+needs of the users, as described in the peer selection pages

The network itself makes use of a significant number of cryptographic techniques and altorithms - a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding, 1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to -station authentication, and ElGamal / AES+SessionTag.

+station authentication, and ElGamal / AES+SessionTag.

Content sent over I2P is encrypted through three or four layers - end to end encryption (absolutely no routers get the plaintext, ever), garlic encryption (used to verify the delivery of the message to @@ -99,9 +98,9 @@ the recipient), tunnel encryption (all messages passing through a tunnel is encr gateway to the tunnel endpoint), and interrouter transport layer encryption (e.g. the TCP transport uses AES256 with ephemeral keys):

-

end to end layered encryption

+

end to end layered encryption

-

The specific use of these algorithms are outlined elsewhere

+

The specific use of these algorithms are outlined elsewhere

The two main mechanisms for allowing people who need militant grade anonymity use the network are explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling @@ -112,7 +111,7 @@ flexible and anonymous transports.

Some questions have been raised with regards to the scalability of I2P, and reasonably so. There will certainly be more analysis over time, but peer lookup and integration should be bounded by -O(log(N)) due to the network database's algorithm, while end to end +O(log(N)) due to the network database's algorithm, while end to end messages should be O(log(1)) (scale free), since messages go out K hops through the outbound tunnel and another K hops through the inbound tunnel - the size of the network (N) bears no impact.

@@ -122,26 +121,26 @@ tunnel and another K hops through the inbound tunnel - the size of the network ( JMS, then grew into its own as an 'anonCommFramework' in April 2003, turning into I2P in July, with code being cut in earnest in August, reaching the 0.2 release in September and 0.3 in March. I2P is currently moving forward according to -the roadmap.

+the roadmap.

The network itself is not ready for general use, and should not be used by those who need anonymity until it has been met with sufficient peer review.

Who?

-

We have a small team spread around several continents, working to advance different +

We have a small team spread around several continents, working to advance different aspects of the project. We are very open to other developers who want to get involved and anyone else who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled applications, or documentation. The entire system is open source - the router and most of the SDK are outright public domain with some BSD and Cryptix licensed code, while some applications like I2PTunnel and I2PSnark are GPL. Almost everything is written in Java (1.3+), though some third party applications -are being written in Python. The code generally works on Kaffe, and +are being written in Python. The code works on the current Kaffe, and we are hoping to get it working on GCJ sooner rather than later.

Where?

Anyone interested should subscribe to the mailing list and -join us on the irc channel #i2p (hosted concurrently on IIP, +join us on the irc channel #i2p (hosted concurrently on IIP, irc.freenode.net, irc.duck.i2p, and irc.baffled.i2p). Weekly development meetings are held there every -Tuesday at 9pm GMT with archives available.

+Tuesday at 9pm GMT with archives available.

The current source is available through an anonymous CVS repository

diff --git a/pages/how_networkcomparisons.html b/pages/how_networkcomparisons.html
index e3a719fc..a41b3e74 100644
--- a/pages/how_networkcomparisons.html
+++ b/pages/how_networkcomparisons.html
@@ -25,15 +25,15 @@ anonymizing proxies, allowing people to tunnel out through the low latency
 mix network.  Morphmix includes some very interesting collusion detection 
 algorithms and Sybil defenses, while Tarzan makes use of the scarcity of IP
 addresses to accomplishs the same.  The two primary differences between 
-these systems and I2P are related to I2P's threat model 
+these systems and I2P are related to I2P's threat model 
 and their out-proxy design (as opposed to providing both sender and receiver 
 anonymity).  There is source code available to both systems, but we are not aware 
 of their use outside of academic environments.

 

 Stealing quite directly from the Tarzan paper, the following includes a quick
-comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:

+comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:

 
-
+
 
 
TOR / Onion Routing

 
@@ -42,37 +42,35 @@ comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:

 

 TOR and Onion Routing are both anonymizing proxy networks, allowing people
 to tunnel out through their low latency mix network.  The two primary 
-differences between TOR / OnionRouting and I2P are again related to differences
-in the threat model and the out-proxy design (though TOR is working to provide 
+differences between TOR / OnionRouting and I2P are again related to differences
+in the threat model and the out-proxy design (though TOR is working to provide 
 redevous points within the mix network, which will provide recipient anonymity).
 In addition, these networks take the directory based approach - providing a 
 centralized point to manage the overall 'view' of the network, as well as gather 
-and report statistics, as opposed to I2P's distributed 
+and report statistics, as opposed to I2P's distributed network 
+database and peer selection.

 
-network database and peer selection.

-
-
On the technical side, there are 5 main differences between TOR and I2P:

+
On the technical side, there are 5 main differences between TOR and I2P:

 
 
 
Mixminion / Mixmaster

@@ -82,8 +80,8 @@ and report statistics, as opposed to I2P's distributed
 
 

 Mixminion and Mixmaster are networks to support anonymous email against a very
-powerful adversary.  I2P aims to provide an adequate means to meet their threat
-model as we reach I2P 3.0 along side the needs of low latency users, providing
+powerful adversary.  I2P aims to provide an adequate means to meet their threat
+model as we reach I2P 3.0 along side the needs of low latency users, providing
 a significantly larger anonymity set.  As with TOR and Onion Routing above, 
 both Mixminion and Mixmaster take the directory based approach as well.

 
@@ -93,12 +91,12 @@ both Mixminion and Mixmaster take the directory based approach as well.

 

 Freenet is a fully distributed, peer to peer anonymous publishing network.  
 As such, generic anonymous communication over it requires the use of the global
-blackboard model - storing data somewhere that the recipient will then check 
+blackboard model - storing data somewhere that the recipient will then check 
 for a message.  Freenet also does not support the concept of user defined delays -
 it stores and fetches data as quickly as it can, rather than queueing up, pooling,
 delaying, and mixing the data, leaving a hole with regards to long term intersection
 attacks.  In addition, there seem to be some performance issues that can arguably
-be attributed to the global blackboard model which will likely rule out interactive
+be attributed to the global blackboard model which will likely rule out interactive
 low latency communication.

 
 
JAP

@@ -109,8 +107,8 @@ low latency communication.

 JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing web requests,
 and as such it has a few centralized nodes (participants in the cascade) that blend
 and mix requests from clients through the sequence of nodes (the cascade) before 
-proxying out onto the web.  The scope, threat model, and security is substantially 
-different from I2P, but for those who don't require significant anonymity but still
+proxying out onto the web.  The scope, threat model, and security is substantially 
+different from I2P, but for those who don't require significant anonymity but still
 are not satisfied with an Anonymizer-like service, JAP is worth reviewing.  One
 caution to note is that anyone under the jurisdiction of the German courts may want
 to take care, as the German Federal Bureau of Criminal Investigation (FBCI) has has 
diff --git a/pages/how_networkdatabase.html b/pages/how_networkdatabase.html
index f00120c8..979b412e 100644
--- a/pages/how_networkdatabase.html
+++ b/pages/how_networkdatabase.html
@@ -1 +1,2 @@
-[not yet written overview of the I2P network database, old content at http://wiki.invisiblenet.net/iip-wiki?NetworkDb]
\ No newline at end of file
+(old version of this page lost... we need a rewrite.  basic gist of it is we follow the 
+guidelines of Kademlia to manage a distributed routing table)
\ No newline at end of file
diff --git a/pages/how_tunnelrouting.html b/pages/how_tunnelrouting.html
index afc560f7..5bd75402 100644
--- a/pages/how_tunnelrouting.html
+++ b/pages/how_tunnelrouting.html
@@ -1,5 +1,5 @@
 

-As briefly explained on the I2P/Overview, I2P builds virtual "tunnels" -
+As briefly explained in the intro, I2P builds virtual "tunnels" -
 temporary and unidirectional paths through a sequence of routers.  These 
 tunnels can be categorized as either inbound tunnels (where everything 
 given to it goes towards the creator of the tunnel) and outbound tunnels
@@ -9,14 +9,16 @@ her existing outbound tunnels with instructions for that tunnel's endpoint
 to forward it to the gateway router for one of Bob's current inbound 
 tunnels, which in turn passes it to Bob.
 

-
+
 

 
 
Tunnel vocabulary

 
 

 

 

 

 

 

 

 
Tunnel information

@@ -113,7 +117,7 @@ tunnels are more complex, but could show similar information (though would be sl
 
 

 With only one remote router in a tunnel, the user has both plausible deniability and basic anonymity, as long
-as they are not up against an internal adversary (as described on I2P/ThreatModel).  However, if the adversary
+as they are not up against an internal adversary (as described on threat model).  However, if the adversary
 ran a sufficient number of routers such that the single remote router in the tunnel is often one of those 
 compromised ones, they would be able to mount the above statistical traffic analysis attack.
 

@@ -135,7 +139,7 @@ pools are refreshed every minute or so, using the router's default settings]
 
Tunnel testing

 
 

-All tunnels are periodically tested by their creator by sending a DeliveryStatusMessage? out the tunnel and bound
+All tunnels are periodically tested by their creator by sending a DeliveryStatusMessage out the tunnel and bound
 for another inbound tunnel (testing both tunnels at once).  If either fails, both are marked as no longer functional,
 and if they were used for a client's inbound tunnel, a new leaseSet is created.  Other techniques can be used to test
 tunnels later on, such as garlic wrapping a number of tests into cloves, testing individual tunnel participants 
@@ -145,21 +149,23 @@ not implemented at the moment.
 
Tunnel creation

 
 

-Tunnel creation is handled by garlic routing (see I2P/GarlicRouting) a TunnelCreateMessage? to a router, 
+Tunnel creation is handled by garlic routing) a TunnelCreateMessage to a router, 
 requesting that they participate in the tunnel (providing them with all of the appropriate information, as above, 
 along with a certificate, which right now is a 'null' cert, but will support hashcash or other non-free certificates 
-when necessary).  The message also includes a SourceRouteReplyBlock?, which allows the router to encrypt their 
-TunnelCreateStatusMessage? into a SourceRouteReplyMessage?, which is sent to another router (specified in the 
-SourceRouteReplyBlock?), who then decrypts the rest of the SourceRouteReplyBlock?, reads out the delivery instructions 
-contained therein, and forwards the TunnelCreateStatusMessage? accordingly.  (the delivery instructions can specify 
+when necessary).  The message also includes a SourceRouteReplyBlock, which allows the router to encrypt their 
+TunnelCreateStatusMessage into a SourceRouteReplyMessage, which is sent to another router (specified in the 
+SourceRouteReplyBlock), who then decrypts the rest of the SourceRouteReplyBlock, reads out the delivery instructions 
+contained therein, and forwards the TunnelCreateStatusMessage accordingly.  (the delivery instructions can specify 
 delivery to a specific router or can point at a tunnel)
 
 

-
Issues

+
Issues/todo

 
 

 

\ No newline at end of file