kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

html cleanup (thanks barkerjr)

Browse Source
This commit is contained in:
jrandom
2005-09-07 22:05:41 +00:00
committed by zzz
parent accba57d69
commit bd3065fff0
6 changed files with 56 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
pages/donate.html
View File

@@ -7,8 +7,8 @@ can make your contribution are provided below:</p>
<td>One time donation:</td>
<td>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_s-xclick">
<input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but04.gif" border="0" name="submit" alt="Make payments with PayPal - it's fast, free and secure!">
<input type="hidden" name="cmd" value="_s-xclick" />
<input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but04.gif" name="submit" alt="Make payments with PayPal - it's fast, free and secure!" />
<input type="hidden" name="encrypted" value="-----BEGIN PKCS7-----
MIIHFgYJKoZIhvcNAQcEoIIHBzCCBwMCAQExggEwMIIBLAIBADCBlDCBjjELMAkG
A1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRQw
@@ -49,7 +49,7 @@ NDNaMCMGCSqGSIb3DQEJBDEWBBRSOWpV+zUddBaL/atCJmn1P97wDDANBgkqhkiG
2We/s4EOaSbYTnuivMVGJf+58tJZej6GGzySbgP1RvUAdxvVC7JVi2xGxV699DsK
osN7CakRqhmOKFbkg7LIIUjIXiybk/oEjMblnj1XLnvK3AN0A5HB0j5s
-----END PKCS7-----
">
" />
</form>
</td>
</tr>
@@ -58,8 +58,8 @@ osN7CakRqhmOKFbkg7LIIUjIXiybk/oEjMblnj1XLnvK3AN0A5HB0j5s
<td>Donate $10/month: </td>
<td>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_s-xclick">
<input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but20.gif" border="0" name="submit" alt="Make payments with PayPal - it's fast, free and secure!">
<input type="hidden" name="cmd" value="_s-xclick" />
<input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but20.gif" name="submit" alt="Make payments with PayPal - it's fast, free and secure!" />
<input type="hidden" name="encrypted" value="-----BEGIN PKCS7-----
MIIHPwYJKoZIhvcNAQcEoIIHMDCCBywCAQExggEwMIIBLAIBADCBlDCBjjELMAkG
A1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRQw
@@ -101,7 +101,7 @@ BIGAQv8rsNUoRnw9CIILiX3YQ40dDKgbcEIv9vsxQnK/bV1B8AOrMgl2PRwJ0XGa
qU/m8s4pmghjkc9MOy8Je6fJrgNQ9ZU0bB+Yw2dCt9Ow1xZuQFsTOGFztB8pWTWs
uzQVonDRMJ5Wol8oHCP0APGhsJo/ym2LUgn8UkapRXLacaY=
-----END PKCS7-----
">
" />
</form>
</td>
</tr></table>
@@ -110,7 +110,7 @@ uzQVonDRMJ5Wol8oHCP0APGhsJo/ym2LUgn8UkapRXLacaY=
<p>Account name: I2P<br />
Account number: 1274080</p>
<form action="https://www.e-gold.com/sci_asp/payments.asp" method="POST" target="_top">
<form action="https://www.e-gold.com/sci_asp/payments.asp" method="post" target="_top">
<input type="hidden" name="PAYEE_ACCOUNT" value="1274080" />
<input type="hidden" name="PAYEE_NAME" value="I2P" />
<input type="hidden" name="PAYMENT_METAL_ID" value="1" />
@@ -146,9 +146,9 @@ Account number: 1274080</p>
</tr>
<tr>
<td></td>
<td><input type="submit" name="PAYMENT_METHOD" value="Donate"></td>
<td><input type="submit" name="PAYMENT_METHOD" value="Donate" /></td>
</tr>
</table>
</form>
</p>
<br /><br />

10
pages/halloffame.html
View File

@@ -4,12 +4,12 @@
If you have made a donation, please send an email to <a href="mailto:adam.wern@gmail.com">Wilde</a>
with you name or nick (and optionally homepage) so we can list you here.
</p>
<p>
<br /><br />
<table border="1">
<tr>
<td><b>Supporting Member</b></td>
<td><b>Amount</b></td>
</tr
</tr>
<tr>
<td><b>New!</b></td>
<td>$10/month</td>
@@ -31,8 +31,8 @@ with you name or nick (and optionally homepage) so we can list you here.
<td>$10/month</td>
</tr>
</table>
</p>
<p>
<br /><br />
<br /><br />
<table border="1">
<tr>
@@ -255,4 +255,4 @@ with you name or nick (and optionally homepage) so we can list you here.
<td>General fund</td>
</tr>
</table>
</p>
<br /><br />

24
pages/how_threatmodel.html
View File

@@ -67,7 +67,7 @@ this list to include new attacks as they are identified.</p>
<li><a href="#impl">Implementation attacks</a></li>
</ul>
<h3><a name="bruteforce">Brute force attacks</a></h3>
<h3 id="bruteforce">Brute force attacks</h3>
<p>A brute force attack can be mounted by a global passive or active adversary,
watching all the messages pass between all of the nodes and attempting to correlate
@@ -93,7 +93,7 @@ database, actively rerouting the associated tunnels 'mid stream', throttling the
inbound tunnels themselves, and/or using restricted routes with trusted links
to secure the local connection.</p>
<h3><a name="timing">Timing attacks</a></h3>
<h3 id="timing">Timing attacks</h3>
<p>I2P's messages are unidirectional and do not necessarily imply that a reply
will be sent. However, applications on top of I2P will most likely have
@@ -117,7 +117,7 @@ increase the latency (per <a href="todo#stop">nontrivial delays</a> or
<a href="todo#batching">batching strategies</a>), include protocol scrubbing, or
other advanced tunnel routing <a href="todo#batching">techniques</a>.</p>
<h3><a name="intersection">Intersection attacks</a></h3>
<h3 id="intersection">Intersection attacks</h3>
<p>Intersection attacks against low latency systems are extremely powerful -
periodically make contact with the target and keep track of what peers are on
@@ -134,7 +134,7 @@ this is only relevent for destinations that other people know about - a private
group whose destination is only known to trusted peers does not have to worry,
as an adversary can't "ping" them to mount the attack.</p>
<h3><a name="dos">Denial of service attacks</a></h3>
<h3 id="dos">Denial of service attacks</h3>
<p>There are a whole slew of denial of service attacks available against I2P,
each with different costs and consequences:</p><ul>
@@ -184,7 +184,7 @@ each with different costs and consequences:</p><ul>
bugs in the implementation.</p>
</ul>
<h3><a name="tagging">Tagging attacks</a></h3>
<h3 id="tagging">Tagging attacks</h3>
<p>Tagging attacks - modifying a message so that it can later be identified
further along the path - are by themselves impossible in I2P, as messages
passed through tunnels are signed. However, if an attacker is the inbound
@@ -197,7 +197,7 @@ collude however, as the tunnel encryption pads and modifies the data seperately
for the inbound and outbound tunnels. External attackers cannot do anything,
as the links are encrypted and messages signed.</p>
<h3><a name="partitioning">Partitioning attacks</a></h3>
<h3 id="partitioning">Partitioning attacks</h3>
<p>Partitioning attacks - finding ways to segregate (technically or analytically)
the peers in a network - are important to keep in mind when dealing with a
@@ -227,7 +227,7 @@ matter, the attacker would need to control a significant portion of the network
(and still that would only be a probabalistic partition, as they wouldn't know
which other tunnels or messages have those delays).</p>
<h3><a name="predecessor">Predecessor attacks</a></h3>
<h3 id="predecessor">Predecessor attacks</h3>
<p>The predecessor attack is passively gathering statistics in an attempt to see
what peers are 'close' to the destination by participating in their tunnels and
@@ -249,7 +249,7 @@ variation of the gateway will look like normal tunnels. Fourth, with
a restricted connection to the target will ever contact the target, while
attackers will merely run into that gateway.</p>
<h3><a name="harvesting">Harvesting attacks</a></h3>
<h3 id="harvesting">Harvesting attacks</h3>
<p>The harvesting attack can be used for legal attacks and to help mounting
other attacks by simply running a peer, seeing who it connects to, and
@@ -265,7 +265,7 @@ this attack loses much of its power, as the "hidden" peers do not publish their
contact addresses in the network database - only the tunnels through which
they can be reached (as well as their public keys, etc).</p>
<h3><a name="sybil">Sybil attacks</a></h3>
<h3 id="sybil">Sybil attacks</h3>
<p>Sybil describes a category of attacks where the adversary creates arbitrarily
large numbers of colluding nodes and uses the increased numbers to help
@@ -283,7 +283,7 @@ Sybil, but do include placeholder certificates in the router's and
destination's data structures which can contain a HashCash certificate of
appropriate value when necessary (or some other certificate proving scarcity).</p>
<h3><a name="crypto">Cryptographic attacks</a></h3>
<h3 id="crypto">Cryptographic attacks</h3>
<p>
We are still assuming the security of the cryptographic primitives explained
@@ -295,7 +295,7 @@ size or garlic messages could be modified randomly so that some cloves appear to
more subcloves than they actually do. At the moment, however, garlic, tunnel, and
end to end messages include simple random padding.</p>
<h3><a name="dev">Development attacks</a></h3>
<h3 id="dev">Development attacks</h3>
<p>
These attacks aren't directly on the network, but instead go after its development team
@@ -320,7 +320,7 @@ However, two techniques help defend against these attacks:
</ul>
</p>
<h3><a name="impl">Implementation attacks</a></h3>
<h3 id="impl">Implementation attacks</h3>
<p>
Try as we might, most nontrivial applications include errors in the design or
implementation, and I2P is no exception. There may be bugs that could be exploited to

10
pages/roadmap.html
View File

@@ -1,9 +1,9 @@
<h2><a name="0.6.1">0.6.1</a></h2>
<h2 id="0.6.1">0.6.1</h2>
<ul>
<li>SSU autoconfiguration and verification</li>
</ul>
<h2><a name="0.6.2">0.6.2</a></h2>
<h2 id="0.6.2">0.6.2</h2>
<ul>
<li>NAT/firewall hole punching support for UDP (SSU introducers)</li>
<li>Update the tunnel pools to include more options for
@@ -11,7 +11,7 @@
light of predecessor attacks.</li>
</ul>
<h2><a name="1.0">1.0</a></h2>
<h2 id="1.0">1.0</h2>
<ul>
<li>Basic content distribution infrastructure, suitable
for address books, blogs, and forums</li>
@@ -19,12 +19,12 @@
<li>Docs</li>
</ul>
<h2><a name="2.0">2.0</a></h2>
<h2 id="2.0">2.0</h2>
<ul>
<li>Full restricted routes</li>
</ul>
<h2><a name="3.0">3.0</a></h2>
<h2 id="3.0">3.0</h2>
<ul>
<li>Tunnel mixing and padding</li>
<li>User defined message delays</li>

16
pages/team.html
View File

@@ -5,7 +5,7 @@ network.</p>
<table border="0">
<tr>
<td valign="top" rowspan="5"><b>Admin</b></td>
<td valign="top"><b>Project Manager<b></td>
<td valign="top"><b>Project Manager</b></td>
<td valign="top">jrandom</td>
<td valign="top"><i>point of contact of last resort</i></td>
</tr>
@@ -15,7 +15,7 @@ network.</p>
<td valign="top"><i>manage donations / accounts / bounties</i></td>
</tr>
<tr>
<td valign="top"><b>Operations Manager<b></td>
<td valign="top"><b>Operations Manager</b></td>
<td valign="top">duck</td>
<td valign="top"><i>monitor network health</i></td>
</tr>
@@ -89,9 +89,9 @@ network.</p>
<td valign="top">cervantes</td>
<td valign="top"><i>fire2pe dev</i></td>
</tr>
<tr>
<td valign="top"><font color="blue">[vacant]</font></td>
<td valign="top"><font color="blue"><i>Help needed on many fronts!</i></font></td>
<tr style="color:blue">
<td valign="top">[vacant]</td>
<td valign="top"><i>Help needed on many fronts!</i></td>
</tr>
<tr><td colspan="4"><hr /></td></tr>
<tr>
@@ -114,9 +114,9 @@ network.</p>
<td valign="top">jrandom</td>
<td valign="top"><i>overview docs, tech docs</i></td>
</tr>
<tr>
<td valign="top"><font color="blue">[vacant]</font></td>
<td valign="top"><font color="blue"><i>help with intro docs, walkthroughs, howtos, and explanatory materials needed!</i></font></td>
<tr style="color: blue">
<td valign="top">[vacant]</td>
<td valign="top"><i>help with intro docs, walkthroughs, howtos, and explanatory materials needed!</i></td>
</tr>
<tr><td colspan="4"><hr /></td></tr>
<tr>

34
pages/todo.html
View File

@@ -12,13 +12,13 @@ up, especially as I2P gets more peer review, but these are the main 'big things'
<li><a href="#netdb">NetworkDB and profile tuning and ejection policy for large nets</a></li>
</ul></li>
<li><a href="#security">Security / anonymity</a><ul>
<li><a href="#tunnelId">Per-hop tunnel id & new permuted TunnelVerificationStructure encryption</a></li>
<li><a href="#tunnelId">Per-hop tunnel id &amp; new permuted TunnelVerificationStructure encryption</a></li>
<li><a href="#ordering">Strict ordering of participants within tunnels</a></li>
<li><a href="#tunnelLength">Randomly permuted tunnel lengths</a></li>
<li><a href="#fullRestrictedRoutes">Full blown n-hop restricted routes with optional trusted links</a></li>
<li><a href="#hashcash">Hashcash for routerIdentity, destination, and tunnel request</a></li>
<li><a href="#batching">Advanced tunnel operation (batching/mixing/throttling/padding)</a></li>
<li><a href="#stop">Stop & go mix w/ garlics & tunnels</a></li>
<li><a href="#stop">Stop &amp; go mix w/ garlics &amp; tunnels</a></li>
</ul></li>
<li><a href="#performance">Performance</a><ul>
<li><a href="#sessionTag">Migrate sessionTag to synchronized PRNG</a></li>
@@ -29,9 +29,9 @@ up, especially as I2P gets more peer review, but these are the main 'big things'
<ul>
<li><h2><a name="core">Core functionality</a></h2><ul>
<li><h2 id="core">Core functionality</h2><ul>
<li><h3><a name="nat">NAT/Firewall bridging via 1-hop restricted routes</a></h3>
<li><h3 id="nat">NAT/Firewall bridging via 1-hop restricted routes</h3>
<p>The functionality of allowing routers to fully participate within
the network while behind firewalls and NATs that they do not control
@@ -81,7 +81,7 @@ and within any given tunnel, two neighboring peers wouldn't want to be hidden.
But that is not technically necessary.</p>
</li>
<li><h3><a name="transport">High degree transport layer with UDP, NBIO, or NIO</a></h3>
<li><h3 id="transport">High degree transport layer with UDP, NBIO, or NIO</h3>
<p>Standard TCP communication in Java generally requires blocking socket calls,
and to keep a blocked socket from hanging the entire system, those blocking calls
@@ -147,7 +147,7 @@ activity on it lately (likely due to 1.4's NIO deployment).</p>
</li>
<li><h3><a name="netdb">NetworkDB and profile tuning and ejection policy for large nets</a></h3>
<li><h3 id="netdb">NetworkDB and profile tuning and ejection policy for large nets</h3>
<p>Within the current network database and profile management implementation, we have taken
the liberty of some practical shortcuts. For instance, we don't have the code to
@@ -167,9 +167,9 @@ mind. We will have some work to do, but we can put it off for later.</p>
</li>
</ul></li>
<li><h2><a name="security">Security / anonymity</a></h2><ul>
<li><h2 id="security">Security / anonymity</h2><ul>
<li><h3><a name="tunnelId">Per-hop tunnel id & new permuted TunnelVerificationStructure encryption</a></h3>
<li><h3 id="tunnelId">Per-hop tunnel id &amp; new permuted TunnelVerificationStructure encryption</h3>
<b><i>Addressed in I2P 0.5 as documented <a href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD">elsewhere</a></i></b>
<p>Right now, if Alice builds a four hop inbound tunnel starting at Elvis, going to Dave,
@@ -206,7 +206,7 @@ samples when dealing with longer tunnels.</p>
</li>
<li><h3><a name="ordering">Strict ordering of participants within tunnels</a></h3>
<li><h3 id="ordering">Strict ordering of participants within tunnels</h3>
<p>As Connelly <a href="http://dev.i2p/pipermail/i2p/2004-July/000335.html">proposed</a>
to deal with the <a href="http://prisms.cs.umass.edu/pubs/wright-tissec.pdf">predecessor attack</a>,
@@ -229,7 +229,7 @@ particularly damning. However, peers with 0-hop tunnels may want to periodicall
MTBF*(tunnel duration) minutes, use a 1-hop tunnel).</p>
</li>
<li><h3><a name="tunnelLength">Randomly permuted tunnel lengths</a></h3>
<li><h3 id="tunnelLength">Randomly permuted tunnel lengths</h3>
<b><i>Addressed in I2P 0.5 as documented <a href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD">elsewhere</a></i></b>
<p>Without tunnel length permutation, if someone were to somehow detect that a destination had
@@ -246,7 +246,7 @@ on the length requested (for example, the 1/MTBF length change for 0-hop tunnels
above).</p>
</li>
<li><h3><a name="fullRestrictedRoutes">Full blown n-hop restricted routes with optional trusted links</a></h3>
<li><h3 id="fullRestrictedRoutes">Full blown n-hop restricted routes with optional trusted links</h3>
<p>The restricted route functionality described before was simply a functional issue - how to let
peers who would not otherwise be able to communicate do so. However, the concept of allowing
@@ -259,7 +259,7 @@ request for delivery to a particular peer and tunnel route that message out one
trusted links with instructions to forward it as requested.</p>
</li>
<li><h3><a name="hashcash">Hashcash for routerIdentity, destination, and tunnel request</a></h3>
<li><h3 id="hashcash">Hashcash for routerIdentity, destination, and tunnel request</h3>
<p>Within the network, we will want some way to deter people from consuming too many resources or
from creating so many peers to mount a <a href="http://citeseer.ist.psu.edu/douceur02sybil.html">sybil</a>
@@ -279,7 +279,7 @@ resources.</p>
"nonfree", and further research on that front is appropriate.</p>
</li>
<li><h3><a name="batching">Advanced tunnel operation (batching/mixing/throttling/padding)</a></h3>
<li><h3 id="batching">Advanced tunnel operation (batching/mixing/throttling/padding)</h3>
<p>To powerful passive external observers as well as large colluding internal observers, standard tunnel
routing is vulnerable to traffic analysis attacks - simply watching the size and frequency of messages
@@ -304,7 +304,7 @@ or to inject additional hops into the path. This can be done by garlic routing
particular peer in a tunnel with instructions to redefine the next-hop in the tunnel.</p>
</li>
<li><h3><a name="stop">Stop & go mix w/ garlics & tunnels</a></h3>
<li><h3 id="stop">Stop &amp; go mix w/ garlics &amp; tunnels</h3>
<p>Beyond the per-tunnel batching and mixing strategy, there are further capabilities for protecting
against powerful attackers, such as allowing each step in a garlic routed path to define a delay or
@@ -315,9 +315,9 @@ pass it along, except at any peers where the clove exposed includes delay instru
</li>
</ul></li>
<li><h2><a name="performance">Performance</a></h2><ul>
<li><h2 id="performance">Performance</h2><ul>
<li><h3><a name="sessionTag">Migrate sessionTag to synchronized PRNG</a></h3>
<li><h3 id="sessionTag">Migrate sessionTag to synchronized PRNG</h3>
<p>Right now, our <a href="how_elgamalaes">ElGamal/AES+SessinTag</a> algorithm works by tagging each
encrypted message with a unique random 32 byte nonce (a "session tag"), identifying that message as
@@ -337,7 +337,7 @@ on demand (with the recipient precalculating the next few possible values to han
delivery).</p>
</li>
<li><h3><a name="streaming">Full streaming protocol improvements</a></h3>
<li><h3 id="streaming">Full streaming protocol improvements</h3>
<p>Since I2P <a href="http://dev.i2p.net/pipermail/i2p/2004-November/000491.html">0.4.2</a>,
we have had a full sliding window streaming library, improving upon the older