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

Fixed URLs in docs/how/intro

Browse Source
This commit is contained in:
str4d
2013-01-31 03:20:24 +00:00
parent b09a7f4099
commit 05df4171d6
1 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
i2p2www/pages/site/docs/how/intro.html
View File

@@ -25,7 +25,7 @@ is quite likely that any outbound proxies to the normal Internet will be monitor
even taken over to attempt more malicious attacks.
{%- endtrans %}</p>
<p>{% trans i2ptunnel=site_url('docs/applications/i2ptunnel') -%}
<p>{% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%}
The network itself is message oriented - it is essentially a secure and anonymous IP layer, 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
@@ -37,7 +37,7 @@ of the I2P enabled applications, or perhaps as a little controller app to turn o
proxies to enable the anonymizing functionality.
{%- endtrans %}</p>
<p>{% trans threatmodel=site_url('docs/how/threatmodel') -%}
<p>{% trans threatmodel=site_url('docs/how/threat-model') -%}
An essential part of designing, developing, and testing an anonymizing network is to define the <a
href="{{ 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
@@ -49,16 +49,16 @@ from the others.
{%- endtrans %}</p>
<h2>{% trans %}Why?{% endtrans %}</h2>
<p>{% trans networkcomparisons=site_url('docs/how/networkcomparisons') -%}
<p>{% trans comparisons=site_url('comparison') -%}
There are a multitude of reasons why we need a system to support anonymous communication, and
everyone has their own personal rationale. There are many <a href="{{ networkcomparisons }}">other
everyone has their own personal rationale. There are many <a href="{{ comparisons }}">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.
{%- endtrans %}</p>
<h2>{% trans %}How?{% endtrans %}</h2>
<p>{% trans tunnelrouting=site_url('docs/how/tunnelrouting'), netdb=site_url('docs/how/networkdatabase') -%}
<p>{% trans tunnelrouting=site_url('docs/how/tunnel-routing'), netdb=site_url('docs/how/network-database') -%}
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="{{ tunnelrouting
}}">tunnel routing</a> page). Each router is identified by a cryptographic RouterIdentity which is
@@ -85,7 +85,7 @@ to those tunnels on the correct router by querying the network database, which i
as new leases are authorized and old ones expire.
{%- endtrans %}</p>
<p>{% trans garlicrouting=site_url('docs/how/garlicrouting') -%}
<p>{% trans garlicrouting=site_url('docs/how/garlic-routing') -%}
If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of
his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2). To make things
easier, most messages sent between Alice and Bob are <a href="{{ garlicrouting }}">garlic</a>
@@ -93,7 +93,7 @@ wrapped, bundling the sender's own current lease information so that the recipie
immediately without having to look in the network database for the current data.
{%- endtrans %}</p>
<p>{% trans peerselection=site_url('docs/how/peerselection') -%}
<p>{% trans peerselection=site_url('docs/how/peer-selection') -%}
To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and
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
@@ -102,7 +102,7 @@ reliability needs of the users, as described in the <a href="{{ peerselection }}
page.
{%- endtrans %}</p>
<p>{% trans crypto=site_url('docs/how/cryptography'), elgamalaes=site_url('docs/how/elgamalaes') -%}
<p>{% trans cryptography=site_url('docs/how/cryptography'), elgamalaes=site_url('docs/how/elgamal-aes') -%}
The network itself makes use of a significant number of <a href="{{ cryptography }}">cryptographic
techniques and algorithms</a> - 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
@@ -128,7 +128,7 @@ applications running atop of I2P.
<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="{% trans %}End to end layered encryption{% endtrans %}" title="{% trans %}End to end layered encryption{% endtrans %}" /></div>
<p>{% trans crypto=site_url('docs/how/cryptography') -%}
<p>{% trans cryptography=site_url('docs/how/cryptography') -%}
The specific use of these algorithms are outlined <a href="{{ cryptography }}">elsewhere</a>.
{%- endtrans %}</p>
@@ -141,7 +141,7 @@ people to set up and operate behind restricted routes (perhaps with trusted peer
deployment of more flexible and anonymous transports.
{%- endtrans %}</p>
<p>{% trans netdb=site_url('docs/how/networkdatabase') -%}
<p>{% trans netdb=site_url('docs/how/network-database') -%}
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="{{ netdb }}">network database</a>'s algorithm, while end
@@ -151,7 +151,7 @@ the network (N) bears no impact.
{%- endtrans %}</p>
<h2>{% trans %}When?{% endtrans %}</h2>
<p>{% trans roadmap=site_url('volunteer/roadmap') -%}
<p>{% trans roadmap=site_url('get-involved/roadmap') -%}
I2P initially began in Feb 2003 as a proposed modification to <a
href="http://freenetproject.org">Freenet</a> to allow it to use alternate transports, such as <a
href="http://java.sun.com/products/jms/index.jsp">JMS</a>, then grew into its own as an
@@ -161,7 +161,7 @@ starting in August '03. I2P is currently under development, following the <a hre
{%- endtrans %}</p>
<h2>{% trans %}Who?{% endtrans %}</h2>
<p>{% trans team=site_url('team') -%}
<p>{% trans team=site_url('about/team') -%}
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,
@@ -173,19 +173,19 @@ on <a href="http://java.com/en/">Sun Java SE</a> and other Java Virtual Machines
{%- endtrans %}</p>
<h2>{% trans %}Where?{% endtrans %}</h2>
<p>{% trans meetings=url_for('meetings_index', lang=g.lang) -%}
<p>{% trans meetings=get_url('meetings_index') -%}
Anyone interested should join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net,
irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de). There are currently no
scheduled development meetings, however <a href="{{ meetings }}">archives are available</a>.
{%- endtrans %}</p>
<p>{% trans monotone=site_url('develop/monotone') -%}
<p>{% trans monotone=site_url('get-involved/guides/monotone') -%}
The current source is available in <a href="{{ monotone }}">monotone</a>.
{%- endtrans %}</p>
<h2>{% trans %}Additional Information{% endtrans %}</h2>
<p>{% trans how_index=site_url('docs/how') -%}
See <a href="{{ how_index}}">the Index to Technical Documentation</a>.
<p>{% trans docs=site_url('docs') -%}
See <a href="{{ docs }}">the Index to Technical Documentation</a>.
{%- endtrans %}</p>
{% endblock %}