From 4d20384c6f73201b97eb7491515ca1d83930efe8 Mon Sep 17 00:00:00 2001 From: jrandom Date: Mon, 19 Jul 2004 16:16:05 +0000 Subject: [PATCH] urls shouldn't end in .html with our index.php thingy (oops) --- pages/bounties.html | 8 ++++---- pages/how_cryptography.html | 6 +++--- pages/how_elgamalaes.html | 4 ++-- pages/how_garlicrouting.html | 8 ++++---- pages/how_intro.html | 28 ++++++++++++++-------------- pages/how_networkcomparisons.html | 6 +++--- pages/how_threatmodel.html | 2 +- pages/how_tunnelrouting.html | 8 ++++---- pages/performance.html | 2 +- pages/roadmap.html | 6 +++--- 10 files changed, 39 insertions(+), 39 deletions(-) diff --git a/pages/bounties.html b/pages/bounties.html index df1aa96a..10f51145 100644 --- a/pages/bounties.html +++ b/pages/bounties.html @@ -22,7 +22,7 @@ etc), and the like.

Name

Status

Judge

Dev *

Bounty

-

MyI2P

+

MyI2P

Proposal in development

jrandom

None yet

@@ -30,7 +30,7 @@ etc), and the like.

-

Streaming library window size

+

Streaming library window size

Proposal in development

[vacant]

None yet

@@ -38,7 +38,7 @@ etc), and the like.

-

Swarming file transfer

+

Swarming file transfer

Proposal in development

[vacant]

None yet

@@ -46,7 +46,7 @@ etc), and the like.

-

Distributed data store

+

Distributed data store

Proposal in development

[vacant]

Nightblade

diff --git a/pages/how_cryptography.html b/pages/how_cryptography.html index ac00d330..ab69955a 100644 --- a/pages/how_cryptography.html +++ b/pages/how_cryptography.html @@ -5,7 +5,7 @@ one asymmetric algorithm, one signing algorithm, and one hashing algorithm. How we do combine them in some particular ways to provide message integrity (rather than relying on a MAC). In addition, as much as we hate doing anything new in regards to cryptography, we can't seem to find a reference discussing (or even naming) the -technique used in ElGamal/AES+SessionTag (but we're sure others have done it). +technique used in ElGamal/AES+SessionTag (but we're sure others have done it).

ElGamal encryption

@@ -32,7 +32,7 @@ can be up to 222 bytes long. Specifically, see [the code].

ElGamal is never used on its own in I2P, but instead always as part of -ElGamal/AES+SessionTag. +ElGamal/AES+SessionTag.

The shared prime is the @@ -137,7 +137,7 @@ TCP connections are currently negotiated with a 2048 Diffie-Hellman implementati 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). Down the line, we will want to use session tags like we do with -ElGamalAES+SessionTag to avoid the 2048bit DH negotiation. +ElGamalAES+SessionTag to avoid the 2048bit DH negotiation.

We would like to migrate to a more standardized implementation (TLS/SSL or even SSH), but:

diff --git a/pages/how_elgamalaes.html b/pages/how_elgamalaes.html index c4ba42cb..ae503c40 100644 --- a/pages/how_elgamalaes.html +++ b/pages/how_elgamalaes.html @@ -19,7 +19,7 @@ is encrypted per encryptNewSession(...) in [ElGamalAESEngine] as follows -

-

An initial ElGamal block, encrypted as before:

+

An initial ElGamal block, encrypted as before:

  |_______1_______2_______3_______4_______5_______6_______7_______8
@@ -36,7 +36,7 @@ as follows -

  |                                                               |
-

Followed by the following, AES encrypted as before, +

Followed by the following, AES encrypted as before, using the session key and IV from the header:

diff --git a/pages/how_garlicrouting.html b/pages/how_garlicrouting.html
index 16d054f0..6e936146 100644
--- a/pages/how_garlicrouting.html
+++ b/pages/how_garlicrouting.html
@@ -1,9 +1,9 @@
 

-As briefly explained on the intro, in addition to sending 
-messages through tunnels (via tunnels), 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 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
@@ -37,7 +37,7 @@ exploiting transport latency/throughput tradeoffs, and branching data through re
 
Encryption

 
 

-The encryption of each layer in the garlic message uses the ElGamal/AES+SessionTag algorithm, 
+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).
 

diff --git a/pages/how_intro.html b/pages/how_intro.html
index b2196f77..77c2db30 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 
@@ -38,20 +38,20 @@ others.

 
Why?

 
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 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 (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 
@@ -66,7 +66,7 @@ as published in the network database.

 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.

 
@@ -74,7 +74,7 @@ duplicates.

 
 
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 
@@ -85,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 
@@ -100,7 +100,7 @@ uses AES256 with ephemeral keys):

 
 
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 
@@ -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(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.

 
@@ -121,13 +121,13 @@ 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 
@@ -140,7 +140,7 @@ we are hoping to get it working on GCJ so
 
Anyone interested should subscribe to the mailing list and 
 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 a41b3e74..7a64e972 100644
--- a/pages/how_networkcomparisons.html
+++ b/pages/how_networkcomparisons.html
@@ -25,7 +25,7 @@ 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.

@@ -47,8 +47,8 @@ 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 network 
-database and peer selection.

+and report statistics, as opposed to I2P's distributed network 
+database and peer selection.

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

 
    
diff --git a/pages/how_threatmodel.html b/pages/how_threatmodel.html
index 0c852ee2..9862bbaf 100644
--- a/pages/how_threatmodel.html
+++ b/pages/how_threatmodel.html
@@ -246,7 +246,7 @@ clock is too far out of sync.
    
 
 
    
 We are still assuming the security of the cryptographic primitives explained 
-elsewhere.  That includes the immediate detection of 
+elsewhere.  That includes the immediate detection of 
 altered messages along the path, the inability to decrypt messages not addressed to you,
 and defense against man-in-the-middle attacks.  The network protocol and data structures
 support securely padding messages to arbitrary sizes, so messages could be made constant
diff --git a/pages/how_tunnelrouting.html b/pages/how_tunnelrouting.html
index 5bd75402..8e51c25c 100644
--- a/pages/how_tunnelrouting.html
+++ b/pages/how_tunnelrouting.html
@@ -1,5 +1,5 @@
 
    
-As briefly explained in the intro, 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
@@ -17,7 +17,7 @@ tunnels, which in turn passes it to Bob.
 
    
 
      
 
    •  Tunnel gateway - the first router in a tunnel.  For inbound tunnels, this is the one mentioned in the 
-        LeaseSet published in the network database.  For outbound tunnels, the 
+        LeaseSet published in the network database.  For outbound tunnels, the 
         gateway is the originating router.  (e.g. both A and D above)
 
    
 
    
@@ -117,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 threat model).  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.
 
    
@@ -149,7 +149,7 @@ not implemented at the moment.
 
    Tunnel creation
    
 
 
    
-Tunnel creation is handled by garlic routing) 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 
diff --git a/pages/performance.html b/pages/performance.html
index 008ae3d9..a5f9684d 100644
--- a/pages/performance.html
+++ b/pages/performance.html
@@ -16,7 +16,7 @@ one function: java.math.BigInteger's
 Rather than try to tune this method, we'll call out to
 GNU MP - an insanely fast math library
 (with tuned assembler for many architectures). (Editor: see
-NativeBigInteger for faster public key cryptography)
    
+NativeBigInteger for faster public key cryptography)
    
 
    ugha and duck are working on the C/JNI glue code, and the existing java code
 is already deployed with hooks for that whenever its ready.  Preliminary results
 look fantastic - running the router with the native GMP modPow is providing over
diff --git a/pages/roadmap.html b/pages/roadmap.html
index e32dfa08..a3a476b6 100644
--- a/pages/roadmap.html
+++ b/pages/roadmap.html
@@ -19,12 +19,12 @@
     allowing the integration of standard .war packages as client applications
 
 
  • New installer and web based config system
    • 
-
  • SAM bridge and client libraries implemented and tested
    • 
+
  • SAM bridge and client libraries implemented and tested
    • 
 

 
 
0.4.1 (July)

 
    
-
  • AMOC transport to allow people behind firewalls/etc to fully participate in I2P
    • 
+
  • AMOC transport to allow people behind firewalls/etc to fully participate in I2P
    • 
 
  • Bandwidth limiter functional
    • 
 
 
  • Router throttling code (detect/adapt to overload by refusing tunnels, shrinking # connections, minimizing networkDb activity)
    • 
@@ -35,7 +35,7 @@
 
  • Javadoc and code walkthrough / guidebook updated
    • 
 
  • Comprehensive management tool available
    • 
 
  • Internal code audit complete
    • 
-
  • MyI2P available
    • 
+
  • MyI2P available
    •