{{ self.title() }}
 }}){kind=logo}
We use AES with 256 bit keys and 128 bit blocks in CBC mode. @@ -376,7 +376,7 @@ NTCP connections are negotiated with a 2048 Diffie-Hellman implementation, using the router's identity to proceed with a station to station agreement, followed by some encrypted protocol specific fields, with all subsequent data encrypted with AES (as above). -The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) forward secrecy', while ElGamalAES+SessionTag does not. +The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) forward secrecy', while ElGamalAES+SessionTag does not.
In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed: diff --git a/i2p2www/pages/site/docs/how/elgamalaes.html b/i2p2www/pages/site/docs/how/elgamalaes.html index 01e45f7c..7fec1547 100644 --- a/i2p2www/pages/site/docs/how/elgamalaes.html +++ b/i2p2www/pages/site/docs/how/elgamalaes.html @@ -142,7 +142,7 @@ The 32-byte Pre-IV will be used to generate the IV for the AES block that follow the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV.
The 222 byte payload is encrypted -using ElGamal +using ElGamal and the encrypted block is 514 bytes long.
@@ -212,7 +212,7 @@ Minimum length: 48 bytes-The data is then AES Encrypted, +The data is then AES Encrypted, using the session key and IV (calculated from the pre-IV) from the ElGamal section. The encrypted AES Block length is variable but is always a multiple of 16 bytes.
diff --git a/i2p2www/pages/site/docs/how/garlicrouting.html b/i2p2www/pages/site/docs/how/garlicrouting.html index cd311d88..ae724089 100644 --- a/i2p2www/pages/site/docs/how/garlicrouting.html +++ b/i2p2www/pages/site/docs/how/garlicrouting.html @@ -42,7 +42,7 @@ During the operating phase, messages are passed through the tunnel, and the message and its routing instructions are only exposed to the endpoint of the tunnel.This is similar to the way Mixmaster -(see network comparisons) 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 @@ -84,7 +84,7 @@ and reliable delivery.
Tunnels are a general-purpose mechanism to transport all I2NP messages, and @@ -134,7 +134,7 @@ the tunnel encryption is sufficient. At the layer above tunnels, I2P delivers end-to-end messages between Destinations. Just as within a single tunnel, we use -ElGamal/AES+SessionTag for the encryption. +ElGamal/AES+SessionTag for the encryption. Each client message as delivered to the router through the I2CP interface becomes a single Garlic Clove @@ -174,7 +174,7 @@ By periodically bundling a LeaseSet, the router ensures that the far-end will be to maintain communications. Otherwise the far-end would have to query a floodfill router for the network database entry, and all LeaseSets would have to be published to the network database, as explained on the -network database page. +network database page.
@@ -191,7 +191,7 @@ and not part of a general-purpose routing scheme.
As a part of -ElGamal/AES encryption, +ElGamal/AES encryption, a garlic message contains a sender specified amount of padding data, allowing the sender to take active countermeasures against traffic analysis. This is not currently used, beyond the requirement to pad to a multiple of 16 bytes.
Encryption of additional messages to and from the -floodfill routers. +floodfill routers.
diff --git a/i2p2www/pages/site/docs/how/index.html b/i2p2www/pages/site/docs/how/index.html index 0d6950df..5f8d149e 100644 --- a/i2p2www/pages/site/docs/how/index.html +++ b/i2p2www/pages/site/docs/how/index.html @@ -21,10 +21,10 @@ If you find any inaccuracies in the documents linked below, pleaseAn 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 good anonymity, mixed in with sufficient cover traffic provided by the activity of people who require less anonymity. This way, some users can avoid @@ -43,20 +43,20 @@ others.
There are a multitude of reasons why we need a system to support anonymous communication, and everyone has their own personal rationale. There 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.
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). +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 (TCP, UDP, etc), 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 securely.
 }} "Network topology example")
If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2). To make things easier, most -messages sent between Alice and Bob are garlic wrapped, bundling the +messages sent between Alice and Bob are garlic wrapped, bundling the sender's own current lease information so that the recipient can reply immediately without having to look in the network database for the current data.
@@ -81,12 +81,12 @@ in the network database for the current data. 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 page. +needs of the users, as described in the peer selection page. -The network itself makes use of a significant number of cryptographic techniques and algorithms - +
The network itself makes use of a significant number of cryptographic techniques and algorithms - 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 layers garlic encryption (used to verify the delivery of the message to the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel @@ -100,7 +100,7 @@ A and h are the routers of Alice and Bob, while Alice and Bob in following chart
 }} "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 strong anonymity to use the network are explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling @@ -111,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(1) (scale free), since messages go out K hops through the outbound
tunnel and another K hops through the inbound tunnel, with K no longer than 3.
The size of the network (N) bears no impact.
-See the Index to Technical Documentation +See the Index to Technical Documentation
{% endblock %} diff --git a/i2p2www/pages/site/docs/how/networkcomparisons.html b/i2p2www/pages/site/docs/how/networkcomparisons.html index 2a15493c..f06dfd5b 100644 --- a/i2p2www/pages/site/docs/how/networkcomparisons.html +++ b/i2p2www/pages/site/docs/how/networkcomparisons.html @@ -37,8 +37,8 @@ supports hidden services as well). In addition, Tor takes 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 network -database and peer selection. +opposed to I2P's distributed network +database and peer selection.The I2P/Tor outproxy functionality does have a few substantial weaknesses against certain attackers - diff --git a/i2p2www/pages/site/docs/how/networkdatabase.html b/i2p2www/pages/site/docs/how/networkdatabase.html index f05d9761..66fee2f4 100644 --- a/i2p2www/pages/site/docs/how/networkdatabase.html +++ b/i2p2www/pages/site/docs/how/networkdatabase.html @@ -506,7 +506,7 @@
- Also discussed on the threat model page. + Also discussed on the threat model page.
A hostile user may attempt to harm the network by @@ -538,7 +538,7 @@
Each router maintains an expanded set of statistics in the - peer profile for each floodfill router, + peer profile for each floodfill router, covering various quality metrics for that peer. The set includes:
@@ -709,7 +709,7 @@ This attack becomes more difficult as the network size grows.This doesn't have much to do with floodfill, but see - the peer selection page + the peer selection page for a discussion of the vulnerabilities of peer selection for tunnels.
@@ -722,8 +722,8 @@ This attack becomes more difficult as the network size grows. This paper addresses weaknesses in the "Finger Table" DHT lookups used by Torsk and NISAN. At first glance, these do not appear to apply to I2P. First, the use of DHT by Torsk and NISAN is significantly different from that in I2P. Second, I2P's network database lookups are only - loosely correlated to the peer selection and - tunnel building processes; only previously-known peers + loosely correlated to the peer selection and + tunnel building processes; only previously-known peers are used for tunnels. Also, peer selection is unrelated to any notion of DHT key-closeness. @@ -739,7 +739,7 @@ This attack becomes more difficult as the network size grows. The floodfill routers are in a position to observe queries and gather information. Certainly, at a level of f = 0.2 (20% malicious nodes, as specifed in the paper) we expect that many of the Sybil threats we describe - (here, + (here, here and here) become problematic for several reasons. diff --git a/i2p2www/pages/site/docs/how/peerselection.html b/i2p2www/pages/site/docs/how/peerselection.html index 693d5c1b..fba7b842 100644 --- a/i2p2www/pages/site/docs/how/peerselection.html +++ b/i2p2www/pages/site/docs/how/peerselection.html @@ -11,14 +11,14 @@ Updated July 2010 for release 0.8Peer profiling is the process of collecting data based on the observed performance of other routers or peers, and classifying those peers into groups. Profiling does not use any claimed performance data published by the peer itself -in the network database. +in the network database.
Profiles are used for two purposes:
diff --git a/i2p2www/pages/site/docs/how/threatmodel.html b/i2p2www/pages/site/docs/how/threatmodel.html index f82c3455..5d265c78 100644 --- a/i2p2www/pages/site/docs/how/threatmodel.html +++ b/i2p2www/pages/site/docs/how/threatmodel.html @@ -24,7 +24,7 @@ More review of existing literature (much of it focused on Tor) and original work focused on I2P is needed.
I2P builds off the ideas of many other +
I2P builds off the ideas of many other systems, but a few key points should be kept in mind when reviewing related literature:
The -network comparisons and -"garlic" terminology pages may also be helpful +network comparisons and +"garlic" terminology pages may also be helpful to review.
@@ -147,7 +147,7 @@ routers contain limits as to how many tunnels can be routed through a single pee As the network grows, these limits are subject to further adjustment. Other mechanisms for peer rating, selection and avoidance are discussed on the -peer selection page. +peer selection page. @@ -203,7 +203,7 @@ Partial defenses implemented in I2P:Also discussed on the - network database page (bootstrap attack). + network database page (bootstrap attack).
I2P avoids this in four ways: first, the peers selected to participate in tunnels are not randomly sampled throughout the network - they are derived from -the peer selection algorithm which breaks them +the peer selection algorithm which breaks them into tiers. Second, with strict ordering of peers in a tunnel, the fact that a peer shows up more frequently does not mean they're the source. Third, with permuted tunnel length @@ -505,7 +505,7 @@ in several IP blocks. However, this is not a meaningful defense against a powerful adversary.
See the - network database page + network database page for more Sybil discussion.
@@ -521,7 +521,7 @@ that a tunnel is formed wholly from its set of colluding routers. The chances of success are enhanced if there is a large number of colluding routers, i.e. a Sybil attack. This is somewhat mitigated by our -peer profiling methods used to monitor the performance +peer profiling methods used to monitor the performance of peers. However, this is a powerful attack as the number of routers approaches f = 0.2, or 20% malicious nodes, as specifed in the paper. @@ -537,7 +537,7 @@ Further research and defenses may be necessary.We use strong cryptography with long keys, and we assume the security of the industry-standard cryptographic primitives used in I2P, as documented -on the low-level cryptography page. +on the low-level cryptography page. Security features include the immediate detection of altered messages along the path, the inability to decrypt messages not addressed to you, @@ -555,7 +555,7 @@ shared secret values while maintaining backward compatibility.
Upgrading the various data structures and protocols to support longer keys will have to be tackled eventually, and this will be a -major undertaking, just as it will be for +major undertaking, just as it will be for others. Hopefully, through careful planning, we can minimize the disruption, and implement mechanisms to make it easier for future transitions. @@ -578,9 +578,9 @@ in the netDb, and the high frequency of communication with those participants. This is somewhat mitigated because floodfill routers only manage a portion of the total keyspace, and the keyspace rotates daily, as explained on the - network database page. + network database page. The specific mechanisms by which routers communicate with floodfills have been - carefully designed. + carefully designed. However, these threats should be studied further. The specific potential threats and corresponding defenses are a topic for future research.
@@ -592,7 +592,7 @@ The specific potential threats and corresponding defenses are a topic for future creating one or more floodfill routers and crafting them to offer bad, slow, or no responses. Several scenarios are discussed on the - network database page. + network database page. diff --git a/i2p2www/pages/site/docs/how/tunnelrouting.html b/i2p2www/pages/site/docs/how/tunnelrouting.html index 43ae9767..28782695 100644 --- a/i2p2www/pages/site/docs/how/tunnelrouting.html +++ b/i2p2www/pages/site/docs/how/tunnelrouting.html @@ -10,7 +10,7 @@ Updated July 2011 for release 0.8.7 This page contains an overview of I2P tunnel terminology and operation, with links to more technical pages, details, and specifications. -As briefly explained in the introduction, I2P builds virtual "tunnels" - +
As briefly explained in the introduction, I2P builds virtual "tunnels" - temporary and unidirectional paths through a sequence of routers. These tunnels are classified as either inbound tunnels (where everything given to it goes towards the creator of the tunnel) or outbound tunnels @@ -35,7 +35,7 @@ F: Inbound Endpoint (Bob)
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 threat model). However, +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.
@@ -190,12 +190,12 @@ DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunne functional. If it was used for a client's inbound tunnel, a new leaseSet is created. Tunnel test failures are also reflected in the -capacity rating in the peer profile. +capacity rating in the peer profile.Tunnel creation is handled by garlic routing +
Tunnel creation is handled by garlic routing a Tunnel Build Message 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 @@ -207,7 +207,7 @@ Details are in the
Multi-layer encryption is handled by garlic encryption +
Multi-layer encryption is handled by garlic encryption of tunnel messages. Details are in the tunnel specification. @@ -245,9 +245,9 @@ tunnel's lifetime may be implemented (e.g. no more than 300 messages or
As mentioned earlier, I2P's netDb works to share the network's metadata. - This is detailed in the networkdatabase page, + This is detailed in the networkdatabase page, but a basic explanation is available below.
@@ -320,7 +320,7 @@ If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers using the Kademlia algorithm. The 'lookup' queries currently function differently, to avoid an important - security issue. + security issue. When a lookup is done, the floodfill router will not forward the lookup to other peers, but will always answer by itself (if it has the requested data).
@@ -576,7 +576,7 @@ What other tunnel peer selection and ordering strategies should be available? the research results of existing systems and papers. While there are a few similar efforts worth reviewing, both for technical and functional comparisons, two in particular are pulled out here - Tor and Freenet. -See also the Network Comparisons Page. +
See also the Network Comparisons Page.