I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Added a macro to simplify inserting site urls

Browse Source
This commit is contained in:
str4d
2012-09-14 02:03:44 +00:00
parent 8e75eeb712
commit 2d0a6c3313
15 changed files with 95 additions and 98 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
i2p2www/pages/global/layout.html
View File

@ -1,3 +1,4 @@
{%- from "global/macros" import site_url with context -%}
<!DOCTYPE html>
<html lang="en">
<head>
@ -10,7 +11,7 @@
<body>
<div class="hide"><a href="#content" title="Skip navigation" accesskey="2">Skip navigation</a></div>
<div id="branding">
<h1 id="logo"><a href="{{ url_for('site_show', lang=g.lang) }}"><img src="{{ url_for('static', filename='images/logo_medium.png') }}" alt="I2P" /></a></h1>
<h1 id="logo"><a href="{{ site_url() }}"><img src="{{ url_for('static', filename='images/logo_medium.png') }}" alt="I2P" /></a></h1>
<div class="title">{{ self.title() }}</div>
</div>
<div class="navigation">

5
i2p2www/pages/global/macros Normal file
View File

@ -0,0 +1,5 @@
{%- macro site_url(path=None) -%}
{%- if path -%}{{ url_for('site_show', lang=g.lang, page=path) }}
{%- else -%}{{ url_for('site_show', lang=g.lang) }}
{%- endif -%}
{%- endmacro -%}

8
i2p2www/pages/global/nav.html
View File

@ -1,13 +1,13 @@
<div id="cssmenu">
<ul>
<li><a href="{{ url_for('site_show', lang=g.lang) }}"><span>Home</span></a></li>
<li><a href="{{ site_url() }}"><span>Home</span></a></li>
<li><a href="{{ url_for('downloads_list', lang=g.lang) }}"><span>Download</span></a></li>
<li class="has-sub"><a href="#"><span>Docs</span></a>
<ul>
<li class="has-sub"><a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}"><span>How does it work?</span></a>
<li class="has-sub"><a href="{{ site_url('docs/how') }}"><span>How does it work?</span></a>
<ul>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/intro') }}"><span>Gentle intro</span></a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/techintro') }}"><span>Tech intro</span></a></li>
<li><a href="{{ site_url('docs/how/intro') }}"><span>Gentle intro</span></a></li>
<li><a href="{{ site_url('docs/techintro') }}"><span>Tech intro</span></a></li>
</ul>
</li>
<li><a href="howto.html"><span>Howto docs</span></a></li>

9
i2p2www/pages/global/urlify
View File

@ -1,9 +0,0 @@
{% macro urlify(url, title, suffix) %}
{% autoescape false %}
{% if static %}
<a href="{{url}}.{{suffix}}">{{title}}</a>
{% else %}
<a href="{{url}}">{{title}}</a>
{% endif %}
{% endautoescape %}
{% endmacro %}

14
i2p2www/pages/site/docs/how/cryptography.html
View File

@ -12,7 +12,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="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> (but we're sure others have done it).
technique used in <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> (but we're sure others have done it).
<p>
<H2><a name="elgamal">ElGamal encryption</a></H2>
@ -25,7 +25,7 @@ To encrypt router-to-router <a href="tunnel-alt-creation.html">Tunnel Build Mess
For end-to-end (destination-to-destination) encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
using the encryption key in the <a href="common_structures_spec.html#struct_LeaseSet">LeaseSet</a>
</li><li>
For encryption of some <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
For encryption of some <a href="{{ site_url('docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
(destination-to-router or router-to-router).
</li></ul>
@ -158,13 +158,13 @@ AES is used for symmetric encryption, in several cases:
<ul><li>
For <a href="#transports">transport encryption</a> after DH key exchange
</li><li>
For end-to-end (destination-to-destination) encryption as a part of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
For end-to-end (destination-to-destination) encryption as a part of <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
</li><li>
For encryption of some <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
as a part of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
For encryption of some <a href="{{ site_url('docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
as a part of <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
(destination-to-router or router-to-router).
</li><li>
For encryption of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}#testing">periodic tunnel test messages</a> sent from the router to itself, through its own tunnels.
For encryption of <a href="{{ site_url('docs/how/tunnelrouting') }}#testing">periodic tunnel test messages</a> sent from the router to itself, through its own tunnels.
</li></ul>
</p><p>
We use AES with 256 bit keys and 128 bit blocks in CBC mode.
@ -376,7 +376,7 @@ NTCP connections are negotiated with a 2048 Diffie-Hellman implementation,
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).
The primary reason to do the DH negotiation instead of using <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> is that it provides '<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">(perfect) forward secrecy</a>', while <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> does not.
The primary reason to do the DH negotiation instead of using <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> is that it provides '<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">(perfect) forward secrecy</a>', while <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> does not.
</p>
<p>
In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed:

4
i2p2www/pages/site/docs/how/elgamalaes.html
View File

@ -142,7 +142,7 @@ The 32-byte Pre-IV will be used to generate the IV for the AES block that follow
the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV.
</p><p>
The 222 byte payload is encrypted
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#elgamal">using ElGamal</a>
<a href="{{ site_url('docs/how/cryptography') }}#elgamal">using ElGamal</a>
and the encrypted block is 514 bytes long.
</p>
@ -212,7 +212,7 @@ Minimum length: 48 bytes
</PRE>
</p><p>
The data is then <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">AES Encrypted</a>,
The data is then <a href="{{ site_url('docs/how/cryptography') }}">AES Encrypted</a>,
using the session key and IV (calculated from the pre-IV) from the ElGamal section.
The encrypted AES Block length is variable but is always a multiple of 16 bytes.
</p>

16
i2p2www/pages/site/docs/how/garlicrouting.html
View File

@ -42,7 +42,7 @@ During the operating phase, messages are passed through the tunnel, and the
message and its routing instructions are only exposed to the endpoint of the tunnel.
</p><p>
This is similar to the way Mixmaster
(see <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">network comparisons</a>) sends messages - taking a message, encrypting it
(see <a href="{{ site_url('docs/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
@ -84,7 +84,7 @@ and reliable delivery.
<h3>ElGamal/AES Encryption</h3>
In some cases, "garlic encryption" may simply mean
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption
<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption
(without multiple layers).
@ -117,7 +117,7 @@ This is described on the
Tunnel building details are defined on
<a href="tunnel-alt-creation.html">this page</a>.
We use
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
</p><p>
Tunnels are a general-purpose mechanism to transport all
<a href="i2np.html">I2NP messages</a>, and
@ -134,7 +134,7 @@ the tunnel encryption is sufficient.
At the layer above tunnels, I2P delivers end-to-end messages between
<a href="common_structures_spec#struct_Destination">Destinations</a>.
Just as within a single tunnel, we use
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
Each client message as delivered to the router through the
<a href="i2cp.html">I2CP interface</a> becomes a single
<a href="i2np.html#struct_GarlicClove">Garlic Clove</a>
@ -174,7 +174,7 @@ By periodically bundling a LeaseSet, the router ensures that the far-end will be
to maintain communications.
Otherwise the far-end would have to query a floodfill router for the network database entry,
and all LeaseSets would have to be published to the network database, as explained on the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database page</a>.
<a href="{{ site_url('docs/how/networkdatabase') }}">network database page</a>.
</li></ol>
</p><p>
@ -191,7 +191,7 @@ and not part of a general-purpose routing scheme.
<h3> Storage to the Floodfill Network Database</h3>
</p>
As explained on the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">network database page</a>,
<a href="{{ site_url('docs/how/networkdatabase') }}#delivery">network database page</a>,
local
<a href="common_structures_spec#struct_LeaseSet">LeaseSets</a>
are sent to floodfill routers in a
@ -220,14 +220,14 @@ as limiting certain routing paths, restricting the types of I2NP messages that m
be forwarded along various paths, and enforcing certain message expiration times.
</p><p>
As a part of
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES encryption</a>,
<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES encryption</a>,
a garlic message contains a sender
specified amount of padding data, allowing the sender to take active countermeasures
against traffic analysis.
This is not currently used, beyond the requirement to pad to a multiple of 16 bytes.
</p><p>
Encryption of additional messages to and from the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">floodfill routers</a>.
<a href="{{ site_url('docs/how/networkdatabase') }}#delivery">floodfill routers</a>.
</p>

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

@ -21,10 +21,10 @@ If you find any inaccuracies in the documents linked below, please
<h3>Overview</h3>
<ul class="helplist">
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/techintro') }}">Technical Introduction</a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/intro') }}">A Less-Technical Introduction</a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">Threat model and analysis</a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">Comparisons to other anonymous networks</a></li>
<li><a href="{{ site_url('docs/techintro') }}">Technical Introduction</a></li>
<li><a href="{{ site_url('docs/how/intro') }}">A Less-Technical Introduction</a></li>
<li><a href="{{ site_url('docs/how/threatmodel') }}">Threat model and analysis</a></li>
<li><a href="{{ site_url('docs/how/networkcomparisons') }}">Comparisons to other anonymous networks</a></li>
<li><a href="protocols.html">Protocol stack chart</a></li>
<li><a href="papers.html">Papers and Presentations on I2P</a></li>
<li><a href="{{ url_for('static', filename='pdf/i2p_philosophy.pdf') }}">Invisible Internet Project (I2P) Project Overview</a> August 28, 2003 (pdf)</li>
@ -101,16 +101,16 @@ Traditionally used only by Java applications and higher-level APIs.
<h3>End-to-End Encryption</h3>
How client messages are end-to-end encrypted by the router.
<ul>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption</li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
<li><a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption</li>
<li><a href="{{ site_url('docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
</ul>
<h3>Network Database</h3>
Distributed storage and retrieval of information about routers and clients.
<ul>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">Network database overview, details, and threat analysis</a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#SHA256">Cryptographic hashes</a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#DSA">Cryptographic signatures</a></li>
<li><a href="{{ site_url('docs/how/networkdatabase') }}">Network database overview, details, and threat analysis</a></li>
<li><a href="{{ site_url('docs/how/cryptography') }}#SHA256">Cryptographic hashes</a></li>
<li><a href="{{ site_url('docs/how/cryptography') }}#DSA">Cryptographic signatures</a></li>
</ul>
<h3>Router Message Protocol</h3>
@ -130,12 +130,12 @@ I2P is a message-oriented router. The messages sent between routers are defined
<h3>Tunnels</h3>
Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.
<ul>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">Peer profiling and selection</a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">Tunnel routing overview</a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">Garlic routing and "garlic" terminology</a></li>
<li><a href="{{ site_url('docs/how/peerselection') }}">Peer profiling and selection</a></li>
<li><a href="{{ site_url('docs/how/tunnelrouting') }}">Tunnel routing overview</a></li>
<li><a href="{{ site_url('docs/how/garlicrouting') }}">Garlic routing and "garlic" terminology</a></li>
<li><a href="tunnel-alt.html">Tunnel building and encryption</a></li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES</a> for build request encryption</li>
<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
<li><a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES</a> for build request encryption</li>
<li><a href="{{ site_url('docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
<li><a href="tunnel-alt-creation.html">Tunnel building specification</a></li>
<li><a href="tunnel_message_spec.html">Low-level tunnel message specification</a></li>
<li><a href="unidirectional-tunnels.html">Unidirectional Tunnels</a></li>
@ -154,9 +154,9 @@ The protocols for direct (point-to-point) router to router communication.
</li><li>
<a href="udp_spec.html">SSU specification</a>
</li><li>
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#tcp">NTCP transport encryption</a>
<a href="{{ site_url('docs/how/cryptography') }}#tcp">NTCP transport encryption</a>
</li><li>
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#udp">SSU transport encryption</a>
<a href="{{ site_url('docs/how/cryptography') }}#udp">SSU transport encryption</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/transport/package-summary.html">Transport Javadoc</a>
</li><li>

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

@ -32,7 +32,7 @@ Instead their view will be of one of the I2P enabled applications, or perhaps as
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="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">threat model</a>, since there is no such thing as "true" anonymity, just
<a href="{{ site_url('docs/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 good anonymity, mixed in with sufficient cover
traffic provided by the activity of people who require less anonymity. This way, some users can avoid
@ -43,20 +43,20 @@ others.</p>
<h2>Why?</h2>
<p>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="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">other efforts</a> working on finding ways to provide varying degrees of
<a href="{{ site_url('docs/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="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">tunnel routing</a> page).
inbound and outbound virtual paths ("tunnels", as outlined on the <a href="{{ site_url('docs/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 (TCP, UDP, etc), 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="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a> (using a modification of
network. I2P has its own internal <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a> (using a modification of
the Kademlia algorithm) for distributing routing and contact information securely.</p>
<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/net.png') }}" alt="Network topology example" title="Network topology example" /></div>
@ -73,7 +73,7 @@ network database, which is constantly updated as new leases are authorized and o
<p>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="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic</a> wrapped, bundling the
messages sent between Alice and Bob are <a href="{{ site_url('docs/how/garlicrouting') }}">garlic</a> wrapped, bundling the
sender's own current lease information so that the recipient can reply immediately without having to look
in the network database for the current data.</p>
@ -81,12 +81,12 @@ in the network database for the current data.</p>
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="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> page.</p>
needs of the users, as described in the <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a> page.</p>
<p>The network itself makes use of a significant number of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">cryptographic techniques and algorithms</a> -
<p>The network itself makes use of a significant number of <a href="{{ site_url('docs/how/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 negotiated connections with station to
station authentication, and <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal / AES+SessionTag</a>.</p>
station authentication, and <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal / AES+SessionTag</a>.</p>
<p>Content sent over I2P is encrypted through three layers garlic encryption (used to verify the delivery of the message to
the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel
@ -100,7 +100,7 @@ A and h are the routers of Alice and Bob, while Alice and Bob in following chart
<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="End to end layered encryption" title="End to end layered encryption." /></div>
<p>The specific use of these algorithms are outlined <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">elsewhere</a>.</p>
<p>The specific use of these algorithms are outlined <a href="{{ site_url('docs/how/cryptography') }}">elsewhere</a>.</p>
<p>The two main mechanisms for allowing people who need strong anonymity to 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="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>'s algorithm, while end to end
<code>O(log(N))</code> due to the <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a>'s algorithm, while end to end
messages should be <code>O(1)</code> (scale free), since messages go out K hops through the outbound
tunnel and another K hops through the inbound tunnel, with K no longer than 3.
The size of the network (N) bears no impact.</p>
@ -144,7 +144,7 @@ There are currently no scheduled development meetings, however
<h2>Additional Information</h2>
<p>
See <a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}">the Index to Technical Documentation</a>
See <a href="{{ site_url('docs/how') }}">the Index to Technical Documentation</a>
</p>
{% endblock %}

4
i2p2www/pages/site/docs/how/networkcomparisons.html
View File

@ -37,8 +37,8 @@ supports hidden services as well). In addition, Tor
takes 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="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network
database</a> and <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a>.</p>
opposed to I2P's distributed <a href="{{ site_url('docs/how/networkdatabase') }}">network
database</a> and <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a>.</p>
<p>The I2P/Tor outproxy functionality does have a few
substantial weaknesses against certain attackers -

12
i2p2www/pages/site/docs/how/networkdatabase.html
View File

@ -506,7 +506,7 @@
<h2 id="threat">Threat Analysis</h2>
<p>
Also discussed on <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#floodfill">the threat model page</a>.
Also discussed on <a href="{{ site_url('docs/how/threatmodel') }}#floodfill">the threat model page</a>.
</p>
<p>
A hostile user may attempt to harm the network by
@ -538,7 +538,7 @@
<h3>Slow or Unresponsive</h3>
<p>
Each router maintains an expanded set of statistics in the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profile</a> for each floodfill router,
<a href="{{ site_url('docs/how/peerselection') }}">peer profile</a> for each floodfill router,
covering various quality metrics for that peer.
The set includes:
</p>
@ -709,7 +709,7 @@ This attack becomes more difficult as the network size grows.
</p>
<p>
This doesn't have much to do with floodfill, but see
the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection page</a>
the <a href="{{ site_url('docs/how/peerselection') }}">peer selection page</a>
for a discussion of the vulnerabilities of peer selection for tunnels.
</p>
@ -722,8 +722,8 @@ This attack becomes more difficult as the network size grows.
This paper addresses weaknesses in the "Finger Table" DHT lookups used by Torsk and NISAN.
At first glance, these do not appear to apply to I2P. First, the use of DHT by Torsk and NISAN
is significantly different from that in I2P. Second, I2P's network database lookups are only
loosely correlated to the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> and
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">tunnel building</a> processes; only previously-known peers
loosely correlated to the <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a> and
<a href="{{ site_url('docs/how/tunnelrouting') }}">tunnel building</a> processes; only previously-known peers
are used for tunnels.
Also, peer selection is unrelated to any notion of DHT key-closeness.
</p>
@ -739,7 +739,7 @@ This attack becomes more difficult as the network size grows.
The floodfill routers are in a position to observe queries and gather information.
Certainly, at a level of <i>f</i> = 0.2 (20% malicious nodes, as specifed in the paper)
we expect that many of the Sybil threats we describe
(<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#sybil">here</a>,
(<a href="{{ site_url('docs/how/threatmodel') }}#sybil">here</a>,
<a href="#sybil">here</a> and
<a href="#sybil-partial">here</a>)
become problematic for several reasons.

6
i2p2www/pages/site/docs/how/peerselection.html
View File

@ -11,14 +11,14 @@ Updated July 2010 for release 0.8
<p><b>Peer profiling</b> is the process of collecting data based on the <b>observed</b> performance
of other routers or peers, and classifying those peers into groups.
Profiling does <b>not</b> use any claimed performance data published by the peer itself
in the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>.
in the <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a>.
<p>
Profiles are used for two purposes:
<ol>
<li>Selecting peers to relay our traffic through, which is discussed below
<li>Choosing peers from the set of floodfill routers to use for network database storage and queries,
which is discussed on the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a> page
which is discussed on the <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a> page
</ol>
@ -38,7 +38,7 @@ All peer selection is done through profiling.
This prevents simple attacks based on peers claiming high bandwidth
in order to capture large numbers of tunnels.
It also makes
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#timing">timing attacks</a>
<a href="{{ site_url('docs/how/threatmodel') }}#timing">timing attacks</a>
more difficult.
</p>
<p>

36
i2p2www/pages/site/docs/how/threatmodel.html
View File

@ -24,7 +24,7 @@ More review of existing literature (much of it focused on Tor) and original
work focused on I2P is needed.</p>
<h2>Network Topology Summary</h2>
<p>I2P builds off the ideas of many <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">other</a>
<p>I2P builds off the ideas of many <a href="{{ site_url('docs/how/networkcomparisons') }}">other</a>
<a href="links">systems</a>, but a few key points should be kept in mind when
reviewing related literature:</p><ul>
<li><b>I2P is a free route mixnet</b> - the message creator explicitly defines the
@ -88,8 +88,8 @@ As we continue to spread the word and grow the network,
these attacks will become much harder.
</p><p>
The
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">network comparisons</a> and
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">"garlic" terminology</a> pages may also be helpful
<a href="{{ site_url('docs/how/networkcomparisons') }}">network comparisons</a> and
<a href="{{ site_url('docs/how/garlicrouting') }}">"garlic" terminology</a> pages may also be helpful
to review.
</p>
@ -147,7 +147,7 @@ routers contain limits as to how many tunnels can be routed through a single pee
As the network grows, these limits are subject to further adjustment.
Other mechanisms for peer rating, selection and avoidance
are discussed on the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection page</a>.
<a href="{{ site_url('docs/how/peerselection') }}">peer selection page</a>.
</p>
@ -203,7 +203,7 @@ Partial defenses implemented in I2P:
<ul><li>
<a href="tunnel-alt.html#ordering">strict ordering</a> of peers
</li><li>
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling and selection</a> from a small group that changes slowly
<a href="{{ site_url('docs/how/peerselection') }}">peer profiling and selection</a> from a small group that changes slowly
</li><li>
Limits on the number of tunnels routed through a single peer
</li><li>
@ -211,7 +211,7 @@ Prevention of peers from the same /16 IP range from being members of a single tu
</li><li>
For eepsites or other hosted services, we support
simultaneous hosting on multiple routers, or
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#intersection">multihoming</a>
<a href="{{ site_url('docs/how/threatmodel') }}#intersection">multihoming</a>
</li></ul>
Even in total, these defenses are not a complete solution.
@ -270,7 +270,7 @@ each with different costs and consequences:</p><ul>
Alternatively, the nodes may provide intermittent service by periodically
dropping selected traffic, or refusing connections to certain peers.
This behavior may be indistinguishable from that of a heavily-loaded or failing node.
I2P addresses these issues by maintaining <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">profiles</a> on the
I2P addresses these issues by maintaining <a href="{{ site_url('docs/how/peerselection') }}">profiles</a> on the
peers, attempting to identify underperforming ones and simply ignoring
them, or using them rarely.
We have significantly enhanced the
@ -305,10 +305,10 @@ each with different costs and consequences:</p><ul>
A floodfill router may provide bad or no response to lookups, and
it may also interfere with inter-floodfill communication.
Some defenses and
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling</a> are implemented,
<a href="{{ site_url('docs/how/peerselection') }}">peer profiling</a> are implemented,
however there is much more to do.
For more information see the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
</li>
</ul>
@ -356,7 +356,7 @@ matter, the attacker would need to control a significant portion of the network
which other tunnels or messages have those delays).
</p><p>
Also discussed on the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a> (bootstrap attack).
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a> (bootstrap attack).
</p>
<h3 id="predecessor">Predecessor attacks</h3>
@ -371,7 +371,7 @@ target is located. </p>
<p>I2P avoids this in four ways: first, the peers selected to participate in
tunnels are not randomly sampled throughout the network - they are derived from
the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> algorithm which breaks them
the <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a> algorithm which breaks them
into tiers. Second, with <a href="tunnel-alt.html#ordering">strict ordering</a> of peers
in a tunnel, the fact that a peer shows up more frequently does not mean they're
the source. Third, with <a href="tunnel-alt.html#length">permuted tunnel length</a>
@ -505,7 +505,7 @@ in several IP blocks.
However, this is not a meaningful defense against a powerful adversary.
</p><p>
See the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>
for more Sybil discussion.
</p>
@ -521,7 +521,7 @@ that a tunnel is formed wholly from its set of colluding routers.
The chances of success are enhanced if there is a large number of colluding routers,
i.e. a <a href="#sybil">Sybil attack</a>.
This is somewhat mitigated by our
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling</a> methods used to monitor the performance
<a href="{{ site_url('docs/how/peerselection') }}">peer profiling</a> methods used to monitor the performance
of peers.
However, this is a powerful attack as the number of routers approaches
<i>f</i> = 0.2, or 20% malicious nodes, as specifed in the paper.
@ -537,7 +537,7 @@ Further research and defenses may be necessary.
<p>
We use strong cryptography with long keys, and
we assume the security of the industry-standard cryptographic primitives used in I2P, as documented
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">on the low-level cryptography page</a>.
<a href="{{ site_url('docs/how/cryptography') }}">on the low-level cryptography page</a>.
Security features
include the immediate detection of
altered messages along the path, the inability to decrypt messages not addressed to you,
@ -555,7 +555,7 @@ shared secret values while maintaining backward compatibility.
</p><p>
Upgrading the various data structures and protocols to support longer keys
will have to be tackled eventually, and this will be a
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">major undertaking</a>, just as it will be for
<a href="{{ site_url('docs/how/cryptography') }}">major undertaking</a>, just as it will be for
<a href="https://torproject.org/">others</a>.
Hopefully, through careful planning, we can minimize the disruption, and
implement mechanisms to make it easier for future transitions.
@ -578,9 +578,9 @@ in the netDb, and the high frequency of communication with those participants.
This is somewhat mitigated because floodfill routers only manage a portion
of the total keyspace, and the keyspace rotates daily, as explained
on the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
The specific mechanisms by which routers communicate with floodfills have been
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">carefully designed</a>.
<a href="{{ site_url('docs/how/networkdatabase') }}#delivery">carefully designed</a>.
However, these threats should be studied further.
The specific potential threats and corresponding defenses are a topic for future research.
</p>
@ -592,7 +592,7 @@ The specific potential threats and corresponding defenses are a topic for future
creating one or more floodfill routers and crafting them to offer
bad, slow, or no responses.
Several scenarios are discussed on the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
</p>

16
i2p2www/pages/site/docs/how/tunnelrouting.html
View File

@ -10,7 +10,7 @@ Updated July 2011 for release 0.8.7
This page contains an overview of I2P tunnel terminology and operation, with
links to more technical pages, details, and specifications.
</p>
<p>As briefly explained in the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}">introduction</a>, I2P builds virtual "tunnels" -
<p>As briefly explained in the <a href="{{ site_url('docs/how') }}">introduction</a>, I2P builds virtual "tunnels" -
temporary and unidirectional paths through a sequence of routers. These
tunnels are classified as either inbound tunnels (where everything
given to it goes towards the creator of the tunnel) or outbound tunnels
@ -35,7 +35,7 @@ F: Inbound Endpoint (Bob)
<ul>
<li class="gap"><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="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>. For outbound tunnels, the
<a href="{{ site_url('docs/how/networkdatabase') }}">network database</a>. For outbound tunnels, the
gateway is the originating router. (e.g. both A and D above)</li>
<li class="gap"><b>Tunnel endpoint</b> - the last router in a tunnel. (e.g. both C and F above)</li>
<li class="gap"><b>Tunnel participant</b> - all routers in a tunnel except for the gateway or
@ -157,7 +157,7 @@ but could show similar information (though would be slightly harder to mount)</p
<h3>1-hop tunnels</h3>
<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="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">threat model</a>). However,
adversary (as described on <a href="{{ site_url('docs/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>
@ -190,12 +190,12 @@ DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunne
functional. If it was used for a client's inbound tunnel, a new leaseSet
is created.
Tunnel test failures are also reflected in the
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}#capacity">capacity rating in the peer profile</a>.
<a href="{{ site_url('docs/how/peerselection') }}#capacity">capacity rating in the peer profile</a>.
</p>
<h2>Tunnel creation</h2>
<p>Tunnel creation is handled by <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic routing</a>
<p>Tunnel creation is handled by <a href="{{ site_url('docs/how/garlicrouting') }}">garlic routing</a>
a Tunnel Build Message 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
@ -207,7 +207,7 @@ Details are in the
<h2>Tunnel encryption</h2>
<p>Multi-layer encryption is handled by <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic encryption</a>
<p>Multi-layer encryption is handled by <a href="{{ site_url('docs/how/garlicrouting') }}">garlic encryption</a>
of tunnel messages.
Details are in the
<a href="tunnel-alt.html">tunnel specification</a>.
@ -245,9 +245,9 @@ tunnel's lifetime may be implemented (e.g. no more than 300 messages or
</li><li>
<a href="tunnel_message_spec.html">tunnel message specification</a>
</li><li>
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic routing</a>
<a href="{{ site_url('docs/how/garlicrouting') }}">garlic routing</a>
</li><li>
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
</li><li>
<a href="i2cp.html#options">I2CP options</a>
</li>

6
i2p2www/pages/site/docs/techintro.html
View File

@ -306,7 +306,7 @@
<h2 id="op.netdb">Network Database</h2>
<p>
As mentioned earlier, I2P's netDb works to share the network's metadata.
This is detailed in <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">the networkdatabase</a> page,
This is detailed in <a href="{{ site_url('docs/how/networkdatabase') }}">the networkdatabase</a> page,
but a basic explanation is available below.
</p>
<p>
@ -320,7 +320,7 @@
If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers
using the <a href="http://en.wikipedia.org/wiki/Kademlia">Kademlia algorithm</a>.
The 'lookup' queries currently function differently, to avoid an important
<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#lookup">security issue</a>.
<a href="{{ site_url('docs/how/networkdatabase') }}#lookup">security issue</a>.
When a lookup is done, the floodfill router will not forward the lookup to other peers,
but will always answer by itself (if it has the requested data).
</p>
@ -576,7 +576,7 @@ What other tunnel peer selection and ordering strategies should be available?
the research results of existing systems and papers. While there are a few
similar efforts worth reviewing, both for technical and functional comparisons,
two in particular are pulled out here - Tor and Freenet. </p>
<p> See also the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">Network Comparisons Page</a>.
<p> See also the <a href="{{ site_url('docs/how/networkcomparisons') }}">Network Comparisons Page</a>.
</p>
<h2 id="similar.tor">Tor</h2>