forked from I2P_Developers/i2p.www
urls shouldn't end in .html with our index.php thingy (oops)
This commit is contained in:
@@ -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>
|
||||
|
@@ -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>
|
||||
|
@@ -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>
|
||||
|
@@ -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>
|
||||
|
@@ -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>
|
||||
|
@@ -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>
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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>
|
||||
|
||||
|
Reference in New Issue
Block a user