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

This commit is contained in:
jrandom
2004-07-19 16:16:05 +00:00
committed by zzz
parent e6108f6715
commit 4d20384c6f
10 changed files with 39 additions and 39 deletions

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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