urls shouldn't end in .html with our index.php thingy (oops)

2004-07-19 16:16:05 +00:00
parent e6108f6715
commit 4d20384c6f
10 changed files with 39 additions and 39 deletions
--- a/pages/bounties.html
+++ b/pages/bounties.html
@@ -22,7 +22,7 @@ etc), and the like.</p>
 <tr><td><p><b>Name</b></p></td><td><p><b>Status</b></p></td><td><p><b>Judge</b></p></td><td><p><b>Dev <sup>*</sup></b></p></td><td><p><b>Bounty</b></p></td></tr>

 <tr>
-  <td><p><b><a href="bounties_myi2p.html">MyI2P</a></b></p></td>
+  <td><p><b><a href="bounties_myi2p">MyI2P</a></b></p></td>
  <td><p>Proposal in development</p></td>
  <td><p>jrandom</p></td>
  <td><p>None yet</p></td>
@@ -30,7 +30,7 @@ etc), and the like.</p>

 </tr>
 <tr>
-  <td><p><b><a href="bounties_windowsize.html">Streaming library window size</a></b></p></td>
+  <td><p><b><a href="bounties_windowsize">Streaming library window size</a></b></p></td>
  <td><p>Proposal in development</p></td>
  <td><p>[vacant]</p></td>
  <td><p>None yet</p></td>
@@ -38,7 +38,7 @@ etc), and the like.</p>

 </tr>
 <tr>
-  <td><p><b><a href="bounties_swarming.html">Swarming file transfer</a></b></p></td>
+  <td><p><b><a href="bounties_swarming">Swarming file transfer</a></b></p></td>
  <td><p>Proposal in development</p></td>
  <td><p>[vacant]</p></td>
  <td><p>None yet</p></td>
@@ -46,7 +46,7 @@ etc), and the like.</p>

 </tr>
 <tr>
-  <td><p><b><a href="bounties_datastore.html">Distributed data store</a></b></p></td>
+  <td><p><b><a href="bounties_datastore">Distributed data store</a></b></p></td>
  <td><p>Proposal in development</p></td>
  <td><p>[vacant]</p></td>
  <td><p><a href="mailto:mpc@innographx.com">Nightblade</a></p></td>
--- 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 <a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a> (but we're sure others have done it).
+technique used in <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> (but we're sure others have done it).
 <p>
 <H2>ElGamal encryption</H2>

@@ -32,7 +32,7 @@ can be up to 222 bytes long.  Specifically, see
 <a href="http://i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/crypto/ElGamalEngine.java">[the code]</a>.
 <p>
 ElGamal is never used on its own in I2P, but instead always as part of 
-<a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a>.
+<a href="how_elgamalaes">ElGamal/AES+SessionTag</a>.
 <p>
 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 
-<a href="how_elgamalaes.html">ElGamalAES+SessionTag</a> to avoid the 2048bit DH negotiation.  
+<a href="how_elgamalaes">ElGamalAES+SessionTag</a> to avoid the 2048bit DH negotiation.  
 <p>
 We would like to migrate to a more standardized implementation (TLS/SSL or even SSH), but:
 <p>
--- a/pages/how_elgamalaes.html
+++ b/pages/how_elgamalaes.html
@@ -19,7 +19,7 @@ is encrypted per encryptNewSession(...) in
 <a href="http://i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/crypto/ElGamalAESEngine.java">[ElGamalAESEngine]</a> 
 as follows -</p>

-<p>An initial ElGamal block, encrypted <a href="how_cryptography.html">as before</a>:</p>
+<p>An initial ElGamal block, encrypted <a href="how_cryptography">as before</a>:</p>

 <PRE>
 |_______1_______2_______3_______4_______5_______6_______7_______8
@@ -36,7 +36,7 @@ as follows -</p>
 |                                                               |
 </PRE>

-<p>Followed by the following, AES encrypted <a href="how_cryptography.html">as before</a>,
+<p>Followed by the following, AES encrypted <a href="how_cryptography">as before</a>,
 using the session key and IV from the header:</p>

 <PRE>
--- a/pages/how_garlicrouting.html
+++ b/pages/how_garlicrouting.html
@@ -1,9 +1,9 @@
 <p>
-As briefly explained on the <a href="how_intro.html">intro</a>, in addition to sending 
-messages through tunnels (via <a href="how_tunnelrouting.html">tunnels</a>), I2P uses a technique called
+As briefly explained on the <a href="how_intro">intro</a>, in addition to sending 
+messages through tunnels (via <a href="how_tunnelrouting">tunnels</a>), 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 <a href="how_networkcomparisons.html">network comparisons</a>) sends messages - taking a message, encrypting it
+(see <a href="how_networkcomparisons">network comparisons</a>) 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
 <H2>Encryption</H2>

 <p>
-The encryption of each layer in the garlic message uses the <a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a> algorithm, 
+The encryption of each layer in the garlic message uses the <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> 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).
 <p>
--- a/pages/how_intro.html
+++ b/pages/how_intro.html
@@ -19,14 +19,14 @@ or even taken over to attempt more malicious attacks.</p>
 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 <a href="http://bitconjurer.org/BitTorrent/">BitTorrent</a> port ("I2PSnark"), 
-or a distributed data store.  With the help of mihi's <a href="i2ptunnel.html">I2PTunnel</a> application, 
+or a distributed data store.  With the help of mihi's <a href="i2ptunnel">I2PTunnel</a> 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.</p>

 <p>An essential part of designing, developing, and testing an anonymizing network is to define the 
-<a href="how_threatmodel.html">threat model</a>, since there is no such thing as "true" anonymity, just 
+<a href="how_threatmodel">threat model</a>, 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.</p>
 <h2>Why?</h2>
 <p>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 
-<a href="how_networkcomparisons.html">other efforts</a> working on finding ways to provide varying degrees of 
+<a href="how_networkcomparisons">other efforts</a> 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.</p>

 <h2>How?</h2>

 <p>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 <a href="how_tunnelrouting.html">tunnel routing</a> page). 
+inbound and outbound virtual paths ("tunnels", as outlined on the <a href="how_tunnelrouting">tunnel routing</a> 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 <a href="how_networkdatabase.html">network database</a> (using a modification of 
+network.  I2P has its own internal <a href="how_networkdatabase">network database</a> (using a modification of 
 the Kademlia algorithm) for distributing routing and contact information.</p>

 <p>The following illustration is a simplistic view regarding how tunnels, routers, and destinations 
@@ -66,7 +66,7 @@ as published in the network database.</p>
 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 <a href="how_tunnelrouting.html">tunnel routing</a>. 
+used to secure these tunnel routed messages, as described <a href="how_tunnelrouting">tunnel routing</a>. 
 In addition, they can be sent in parallel down multiple tunnels, with the last router discarding 
 duplicates.</p>

@@ -74,7 +74,7 @@ duplicates.</p>

 <p>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 
-<a href="how_garlicrouting.html">garlic routing</a>. Inspired by a subsection for future works written by 
+<a href="how_garlicrouting">garlic routing</a>. Inspired by a subsection for future works written by 
 Michael Freedman within Roger Dingledine's freehaven 
 <a href="http://www.freehaven.net/doc/freehaven10.ps">thesis</a>, and with some similarities to 
 <a href="http://onion-router.net/">onion routing</a>.  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 <a href="how_peerselection.html">peer selection</a> pages</p>
+needs of the users, as described in the <a href="how_peerselection">peer selection</a> pages</p>

 <p>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 <a href="how_elgamalaes.html">ElGamal / AES+SessionTag</a>.</p>
+station authentication, and <a href="how_elgamalaes">ElGamal / AES+SessionTag</a>.</p>

 <p>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):</p>

 <p><img src="http://dev.i2p.net/~jrandom/endToEndEncryption.png" alt="end to end layered encryption" /></p>

-<p>The specific use of these algorithms are outlined <a href="how_cryptography.html">elsewhere</a></p>
+<p>The specific use of these algorithms are outlined <a href="how_cryptography">elsewhere</a></p>

 <p>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.</p>

 <p>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 
-<code>O(log(N))</code> due to the <a href="how_networkdatabase.html">network database</a>'s algorithm, while end to end 
+<code>O(log(N))</code> due to the <a href="how_networkdatabase">network database</a>'s algorithm, while end to end 
 messages should be <code>O(log(1))</code> (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.</p>

@@ -121,13 +121,13 @@ tunnel and another K hops through the inbound tunnel - the size of the network (
 <a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, 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 <a href="roadmap.html">roadmap</a>.</p>
+the <a href="roadmap">roadmap</a>.</p>

 <p>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.</p>

 <h2>Who?</h2>
-<p>We have a small <a href="team.html">team</a> spread around several continents, working to advance different 
+<p>We have a small <a href="team">team</a> 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 <a href="http://gcc.gnu.org/java/">GCJ</a> so
 <p>Anyone interested should subscribe to the <a href="http://i2p.net/pipermail/i2p/">mailing list</a> and 
 join us on the irc channel #i2p (hosted concurrently on <a href="http://invisiblechat.com/">IIP</a>,
 irc.freenode.net, irc.duck.i2p, and irc.baffled.i2p). Weekly development meetings are held there every 
-Tuesday at 9pm GMT with <a href="meetings.html">archives available</a>.</p>
+Tuesday at 9pm GMT with <a href="meetings">archives available</a>.</p>

 <p>The current source is available through an anonymous CVS repository</p>
 	<pre>
--- 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 <a href="how_threatmodel.html">threat model</a> 
+these systems and I2P are related to I2P's <a href="how_threatmodel">threat model</a> 
 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.</p>
@@ -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 <a href="how_networkdatabase.html">network 
-database</a> and <a href="how_peerselection.html">peer selection</a>.</p>
+and report statistics, as opposed to I2P's distributed <a href="how_networkdatabase">network 
+database</a> and <a href="how_peerselection">peer selection</a>.</p>

 <p>On the technical side, there are 5 main differences between TOR and I2P:</p>
 <ul>
--- a/pages/how_threatmodel.html
+++ b/pages/how_threatmodel.html
@@ -246,7 +246,7 @@ clock is too far out of sync.</p>

 <p>
 We are still assuming the security of the cryptographic primitives explained 
-<a href="how_cryptography.html">elsewhere</a>.  That includes the immediate detection of 
+<a href="how_cryptography">elsewhere</a>.  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
--- a/pages/how_tunnelrouting.html
+++ b/pages/how_tunnelrouting.html
@@ -1,5 +1,5 @@
 <p>
-As briefly explained in the <a href="how_intro.html">intro</a>, I2P builds virtual "tunnels" -
+As briefly explained in the <a href="how_intro">intro</a>, 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.
 <p>
 <UL>
 <li> <b>Tunnel gateway</b> - the first router in a tunnel.  For inbound tunnels, this is the one mentioned in the 
-        LeaseSet published in the <a href="how_networkdatabase.html">network database</a>.  For outbound tunnels, the 
+        LeaseSet published in the <a href="how_networkdatabase">network database</a>.  For outbound tunnels, the 
        gateway is the originating router.  (e.g. both A and D above)
 </UL>
 <p>
@@ -117,7 +117,7 @@ tunnels are more complex, but could show similar information (though would be sl

 <p>
 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 <a href="how_threatmodel.html">threat model</a>).  However, if the adversary
+as they are not up against an internal adversary (as described on <a href="how_threatmodel">threat model</a>).  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.
 <p>
@@ -149,7 +149,7 @@ not implemented at the moment.
 <H2>Tunnel creation</H2>

 <p>
-Tunnel creation is handled by <a href="how_garlicrouting.html">garlic routing</a>) a TunnelCreateMessage to a router, 
+Tunnel creation is handled by <a href="how_garlicrouting">garlic routing</a>) 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 
--- 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
 <a href="http://www.swox.com/gmp/">GNU MP</a> - an insanely fast math library
 (with tuned assembler for many architectures). (<i>Editor: see
-<a href="jbigi.html">NativeBigInteger for faster public key cryptography</a></i>)</p>
+<a href="jbigi">NativeBigInteger for faster public key cryptography</a></i>)</p>
 <p>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
--- a/pages/roadmap.html
+++ b/pages/roadmap.html
@@ -19,12 +19,12 @@
    allowing the integration of standard .war packages as client applications</li>

 <li>New installer and web based config system</li>
-<li><a href="sam.html">SAM</a> bridge and client libraries implemented and tested</li>
+<li><a href="sam">SAM</a> bridge and client libraries implemented and tested</li>
 </ul>

 <h2>0.4.1 (July)</h2>
 <ul>
-<li><a href="amoc.html">AMOC</a> transport to allow people behind firewalls/etc to fully participate in I2P</li>
+<li><a href="amoc">AMOC</a> transport to allow people behind firewalls/etc to fully participate in I2P</li>
 <li>Bandwidth limiter functional</li>

 <li>Router throttling code (detect/adapt to overload by refusing tunnels, shrinking # connections, minimizing networkDb activity)</li>
@@ -35,7 +35,7 @@
 <li>Javadoc and code walkthrough / guidebook updated</li>
 <li>Comprehensive management tool available</li>
 <li>Internal code audit complete</li>
-<li><a href="myi2p.html">MyI2P</a> available</li>
+<li><a href="myi2p">MyI2P</a> available</li>

 </ul>