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

propagate from branch 'i2p.www' (head 56805f1c287e5d3c3f99a1d379eedb7546b3f871)

Browse Source 
to branch 'i2p.www.revamp' (head acf206607b2261559baba585f66b9c2b0d528bca)
This commit is contained in:
str4d
2012-10-03 05:24:30 +00:00
parent a404bbf706 00ef914a5a
commit 2b8d341e4f
1071 changed files with 47321 additions and 44528 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
i2p2www/pages/blog/entry.html Normal file
View File

@@ -0,0 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{{ title }} - Blog{% endblock %}
{% block content %}
{% autoescape false %}
{{ body }}
{% endautoescape %}
{% endblock %}

10
i2p2www/pages/blog/index.html Normal file
View File

@@ -0,0 +1,10 @@
{% extends "global/layout.html" %}
{% block title %}Blog Index{% endblock %}
{% block content %}
<p>Some descriptive text.</p>
<ul class="infolist">
{% for entry in entries -%}
<li>{{ entry[1] }} - <a href="{{ url_for('blog_entry', slug=entry[0]) }}">{{ entry[2] }}</a></li>
{%- endfor %}
</ul>
{% endblock %}

12
i2p2www/pages/blog/latest.html Normal file
View File

@@ -0,0 +1,12 @@
<ul>
<li>2012-07-30 - <a href="release-0.9.1.html">I2P 0.9.1 Released</a></li>
<li>2012-05-02 - <a href="release-0.9.html">I2P 0.9 Released</a></li>
<li>2012-02-27 - <a href="release-0.8.13.html">I2P 0.8.13 Released</a></li>
<li>2012-01-06 - <a href="release-0.8.12.html">I2P 0.8.12 Released</a></li>
<li>2011-03-02 - <a href="release-0.8.4.html">I2P 0.8.4 Released</a></li>
<li>2011-03-01 - <a href='#'>Coding Moratorium & New Site </a></li>
<li>2011-01-24 - <a href="release-0.8.3.html">I2P 0.8.3 Released</a></li>
<li>2011-01-01 - <a href='#'>I2P at HOPE, Pegasus Project</a></li>
<li>2010-12-22 - <a href="release-0.8.2.html">I2P 0.8.2 Released</a></li>
<li>2010-11-15 - <a href="release-0.8.1.html">I2P 0.8.1 Released</a></li>
</ul>

143
i2p2www/pages/downloads/list.html Normal file
View File

@@ -0,0 +1,143 @@
{% extends "global/layout.html" %}
{% block title %}Download{% endblock %}
{% block content %}
<h1>Download I2P</h1>
<h3>Dependency</h3>
Java Runtime 1.5 or higher.
(<a href="http://java.com/download/">Oracle/Sun Java Version 6</a>,
<a href="http://openjdk.java.net/install/">OpenJDK 6</a>, or
<a href="http://icedtea.classpath.org/wiki/Main_Page">IcedTea6</a>
recommended)
<br />
<a href="http://java.com/en/download/installed.jsp?detect=jre&amp;try=1">Determine your installed Java version here</a>
or type <tt>java -version</tt> at your command prompt.
<h3>Clean installs</h3>
<ul class="downloadlist">
<li><b>Windows Graphical installer:</b><br />
<a href="http://mirror.i2p2.de/i2pinstall_0.9.2_windows.exe">i2pinstall_0.9.2_windows.exe</a>
(SHA256
4cc506d74bea772d304a8fc1d4adee900e5d7d38cbf896bd8aa9de31002b4f43
<a href="http://mirror.i2p2.de/i2pinstall_0.9.2_windows.exe.sig">sig</a>)<br />
Download that file and run it.
</li>
<li><b>Linux / OS X / BSD / Solaris Graphical installer:</b><br />
<a href="http://mirror.i2p2.de/i2pinstall_0.9.2.jar">i2pinstall_0.9.2.jar</a>
(SHA256
7eb1b62bdb955691dfd645acc2172fe7947266e35f201273f702272d57b80a70
<a href="http://mirror.i2p2.de/i2pinstall_0.9.2.jar.sig">sig</a>)<br />
Download that file and double-click it (if that works) or
type <code>java -jar i2pinstall_0.9.2.jar</code> in a terminal to run the
installer.
On some platforms you may be able to right-click and select
&quot;Open with Java&quot;.</li>
<li><b>Linux / OS X / BSD / Solaris Command line (headless) install:</b><br />
Download the graphical installer file above and
run <code>java -jar i2pinstall_0.9.2.jar -console</code> from the command line.
</li>
<li><a href="/debian.html">Packages for Debian &amp; Ubuntu</a></li>
<li><b>Source install:</b><br />
<a href="http://mirror.i2p2.de/i2psource_0.9.2.tar.bz2">i2psource_0.9.2.tar.bz2</a>
(SHA256
ac0262120868a01d11b27ce56a7fea5ea243e261d0d7ff6e6dd59e18987a1be5
<a href="http://mirror.i2p2.de/i2psource_0.9.2.tar.bz2.sig">sig</a>)<br />
Alternately, you can fetch the source from <a href="newdevelopers">monotone</a>.
<br />
Run <code>(tar xjvf i2psource_0.9.2.tar.bz2 ; cd i2p-0.9.2 ; ant pkg)</code> then either
run the GUI installer or headless install as above</li>
</ul>
The files are signed by zzz,
<a href="release-signing-key.html">whose key is here</a>.
<p>I2P can also be downloaded from our project pages on <a href="https://launchpad.net/i2p/trunk">Launchpad</a> and <a href="http://code.google.com/p/i2p/">Google Code</a>.</p>
<h3>Post-install work</h3>
<p>After running the installer on windows, simply click on the "Start I2P" button
which will bring up the <a href="http://localhost:7657/index.jsp">router console</a>,
which has further instructions.</p>
<p>On Unix-like systems, I2P can be started as a service
using the "i2prouter" script, located in the directory you selected for I2P.
Changing to that directory in a console and issuing "sh i2prouter status"
should tell you the router's status. The arguments "start", "stop" and "restart"
control the service. The <a href="http://localhost:7657/index.jsp">router console</a>
can be accessed at its usual location.
For users on OpenSolaris and other systems for which the wrapper (i2psvc) is not supported,
start the router with "sh runplain.sh" instead.
</p>
<p>When installing for the first time, please remember to <b>adjust your NAT/firewall</b>
if you can, bearing in mind the Internet-facing ports I2P uses,
<a href="faq#ports">described here</a> among other ports.
If you have successfully opened your port to inbound TCP, also enable inbound TCP on the
<a href="http://localhost:7657/confignet.jsp">configuration page</a>.
</p>
<p>Also, please review and <b>adjust the bandwidth settings</b> on the
<a href="http://localhost:7657/config.jsp">configuration page</a>,
as the default settings of 96 KBps down / 40 KBps up are fairly slow.
</p>
<p>
If you want to reach eepsites via your browser, have a look on the <a href="htproxyports.html">browser proxy setup</a> page for an easy howto.
</p>
<h3>Updates from earlier releases:</h3>
<p>
Both automatic and manual upgrades are available for the release.
</p><p>
If you are running 0.7.5 or later, your router should detect the
new release. To upgrade simply click the 'Download Update' button on your router console
when it appears.
</p><p>
Due to a bug in release 0.7.6, those whose first I2P installation was that version
and have not upgraded manually
may get a "downloaded version is not greater than current version" error,
and should use the manual update method below.
</p><p>
If you are running 0.7.4 or earlier, please see
<a href="release-0.7.5.html">the 0.7.5 release notes</a>
for important information about how to configure your router to automatically
receive the release.
</p><p>
If you are running 0.6.1.30 or earlier, please see
<a href="upgrade-0.6.1.30.html">instructions</a>
for important information about how to configure your router to automatically
receive the release.
</p>
<ol>
<li>If you have reconfigured your router following the <a href="upgrade-0.6.1.30.html">instructions</a>, you should see a link on your
<a href="http://localhost:7657/index.jsp">router console</a> allowing
you to download and install the new release by just clicking on that
link.</li>
<li>Alternately, you can use the manual method specified below.</li>
</ol>
<h3>Updates from earlier releases (manual method):</h3>
<ol>
<li>Download <a href="http://mirror.i2p2.de/i2pupdate_0.9.2.zip">i2pupdate_0.9.2.zip</a>
(SHA256
c547b81822ff642e52a9196e847466b5613219fc695bc26485930c7a855e0cee
<a href="http://mirror.i2p2.de/i2pupdate_0.9.2.zip.sig">sig</a>) to your I2P
installation directory and <b>rename as i2pupdate.zip</b>.
(alternately, you can get the source as above and run "ant updater", then copy the
resulting i2pupdate.zip to your I2P installation directory). You do
NOT need to unzip that file.</li>
<li>Click <a href="http://localhost:7657/configservice.jsp">"Restart"</a></li>
<li>Grab a cup of coffee and come back in 11 minutes</li>
</ol>
The file is signed by zzz,
<a href="release-signing-key.html">whose key is here</a>.
<h3>Previous Releases</h3>
Previous releases are available on <a href="http://code.google.com/p/i2p/downloads/list?can=1">Google Code</a>
and <a href="https://launchpad.net/i2p/trunk">Launchpad</a>
and within the I2P network on <a href="http://echelon.i2p/">echelon.i2p</a>.
{% endblock %}

13
i2p2www/pages/global/error_404.html Normal file
View File

@@ -0,0 +1,13 @@
{% extends "global/layout.html" %}
{% block title -%}
{% trans -%}
Not found
{%- endtrans %}
{%- endblock %}
{% block content %}
{% trans -%}
Yep... the resource, you were searching for, is named differently, doesn't exist or was removed.
{%- endtrans %}
{% endblock %}

12
i2p2www/pages/global/error_500.html Normal file
View File

@@ -0,0 +1,12 @@
{% extends "global/layout.html" %}
{% block title -%}
{% trans -%}
Server error
{%- endtrans %}
{%- endblock %}
{% block content %}
{% trans -%}
Umm... the server encountered some sort of error.
{%- endtrans %}
{% endblock %}

40
i2p2www/pages/global/footer.html Normal file
View File

@@ -0,0 +1,40 @@
<div class='aside first'>
<h1>{{ _('News') }}</h1>
<ul>
<li><a href="{{ url_for('blog_index', lang=g.lang) }}">{{ _('Blog') }}</a></li>
<li><a href="{{ url_for('meetings_index', lang=g.lang) }}">{{ _('Meetings') }}</a></li>
</ul>
</div>
<div class='aside second'>
<h1>{{ _('About I2P') }}</h1>
<ul>
<li><a href="team.html">{{ _('I2P Team') }}</a></li>
<li><a href="halloffame.html">{{ _('Hall of Fame') }}</a></li>
</ul>
</div>
<div class='aside third'>
<h1>{{ _('Mirrors') }}</h1>
<ul>
<li><a rel="nofollow" href="http://i2pproject.net/">http://i2pproject.net</a></li>
<li><a rel="nofollow" href="http://i2p.us/">http://i2p.us</a></li>
<li><a rel="nofollow" href="http://i2p-projekt.de/">http://i2p-projeckt.de</a></li>
</ul>
</div>
<div class='aside fourth'>
<h1>{{ _('Secure') }}</h1>
<ul>
<li><a rel="nofollow" href="https://www.i2p2.de/">https://www.i2p2.de</a></li>
<li><a rel="nofollow" href="https://i2p.us/">https://i2p.us</a></li>
</ul>
</div>
<div class='aside fifth'>
<h1>{{ _('Misc.') }}</h1>
<ul>
<li><a href="http://syndie.i2p2.de/">Syndie</a></li>
<li><a href="links.html">{{ _('Links') }}</a></li>
<li><a href="{{ site_url('impressum') }}">{{ _('Impressum') }}</a></li>
</ul>
</div>
<div class='aside sixth'>
<a class='button' href="{{ site_url('volunteer/donate') }}">{{ _('Donate') }}</a>
</div>

13
i2p2www/pages/global/lang.html Normal file
View File

@@ -0,0 +1,13 @@
<ul class="languages">
<li><a href="{{ change_lang('en') }}"><img src="{{ url_for('static', filename='images/us.png') }}" alt="English" /></a></li>
<li><a href="{{ change_lang('es') }}"><img src="{{ url_for('static', filename='images/es.png') }}" alt="Castellano" /></a></li>
<li><a href="{{ change_lang('zh') }}"><img src="{{ url_for('static', filename='images/zh.png') }}" alt="Chinese" /></a></li>
<li><a href="{{ change_lang('de') }}"><img src="{{ url_for('static', filename='images/de.png') }}" alt="Deutsch" /></a></li>
<li><a href="{{ change_lang('fr') }}"><img src="{{ url_for('static', filename='images/fr.png') }}" alt="Français" /></a></li>
<li><a href="{{ change_lang('it') }}"><img src="{{ url_for('static', filename='images/it.png') }}" alt="Italiano" /></a></li>
<li><a href="{{ change_lang('nl') }}"><img src="{{ url_for('static', filename='images/nl.png') }}" alt="Nederlands" /></a></li>
<li><a href="{{ change_lang('ru') }}"><img src="{{ url_for('static', filename='images/ru.png') }}" alt="Russian" /></a></li>
<li><a href="{{ change_lang('sv') }}"><img src="{{ url_for('static', filename='images/sv.png') }}" alt="Svenska" /></a></li>
<li><a href="{{ change_lang('cs') }}"><img src="{{ url_for('static', filename='images/cs.png') }}" alt="Czech" /></a></li>
<li><a href="{{ change_lang('ar') }}"><img src="{{ url_for('static', filename='images/ar.png') }}" alt="Arabic" /></a></li>
</ul>

31
i2p2www/pages/global/layout.html Normal file
View File

@@ -0,0 +1,31 @@
{%- from "global/macros" import site_url, change_lang with context -%}
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>{% block title %}{% endblock %} - I2P</title>
<link rel="stylesheet" type="text/css" href="{{ url_for('static', filename='styles/' + g.theme + '.css') }}" title="{{ g.theme }}" />
<link rel="shortcut icon" type="image/x-icon" href="{{ url_for('static', filename='favicon.ico') }}" />
<meta name="robots" content="NOODP" />
</head>
<body>
<div class="hide"><a href="#content" title="Skip navigation" accesskey="2">{{ _('Skip navigation') }}</a></div>
<div id="branding">
<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">
{% include "global/nav.html" %}
</div>
<div id="content">
{% block content_outer %}
<div class="inner">
{% block content %}{% endblock %}
</div>
{% endblock %}
</div>
<div id="footer">
{% include "global/footer.html" %}
</div>
</body>
</html>

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

@@ -0,0 +1,13 @@
{%- 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 -%}
{%- macro change_lang(lang) -%}
{%- if request.endpoint == 'site_show' -%}{{ url_for('site_show', lang=lang, page=page) }}
{%- elif request.endpoint == 'blog_entry' -%}{{ url_for('blog_entry', lang=lang, slug=slug) }}
{%- elif request.endpoint == 'meetings_show' -%}{{ url_for('meetings_show', lang=lang, id=id) }}
{%- elif request.endpoint -%}{{ url_for(request.endpoint, lang=lang) }}
{%- else -%}{{ url_for('site_show', lang=lang) }}
{%- endif -%}
{%- endmacro -%}

42
i2p2www/pages/global/nav.html Normal file
View File

@@ -0,0 +1,42 @@
<div id="cssmenu">
<ul>
<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="{{ site_url('docs/how') }}"><span>{{ _('How does it work?') }}</span></a>
<ul>
<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>
<li><a href="applications.html"><span>{{ _('Applications') }}</span></a></li>
</ul>
</li>
<li class="has-sub"><a href="#"><span>{{ _('Support') }}</span></a>
<ul>
<li><a href="{{ site_url('support/faq') }}"><span>{{ _('FAQ') }}</span></a></li>
<li><a href="http://forum.i2p2.de/"><span>{{ _('Forums') }}</span></a></li>
<li><a href="http://trac.i2p2.i2p/"><span>Trac</span></a></li>
</ul>
</li>
<li class="has-sub"><a href="#"><span>{{ _('Develop') }}</span></a>
<ul>
<li><a href="{{ site_url('develop/api') }}"><span>{{ _('API') }}</span></a></li>
<li><a href="{{ site_url('develop/applications') }}"><span>{{ _('Applications') }}</span></a></li>
<li><a href="{{ site_url('develop/licenses') }}"><span>{{ _('Licenses') }}</span></a></li>
</ul>
</li>
<li class="has-sub"><a href="{{ site_url('volunteer') }}"><span>{{ _('Volunteer') }}</span></a>
<ul>
<li><a href="{{ site_url('volunteer/bounties') }}"><span>{{ _('Bounties') }}</span></a></li>
<li><a href="roadmap.html"><span>{{ _('Roadmap') }}</span></a></li>
<li><a href="todo.html"><span>{{ _('Task list') }}</span></a></li>
</ul>
</li>
<li class="has-sub right"><a href="#"><span>{{ _('Language') }}</span></a>
{% include "global/lang.html" %}
</li>
</ul>
</div>

187
i2p2www/pages/meetings/index.html Normal file
View File

@@ -0,0 +1,187 @@
{% extends "global/layout.html" %}
{% block title %}Meetings{% endblock %}
{% block content %}
<h1>Logs of past I2P meetings</h1>
<p>Regularly scheduled meetings are not being held at this time.
If you have something to discuss, please find the developers on IRC in #i2p-dev.
<a href="{{ url_for('blog_index', lang=g.lang) }}">Status updates</a> from developers are also available.
</p><div class="underline"></div>
<ul class="infolist">
{%- macro meeting_url(m_id) -%}{{ url_for('meetings_show', lang=g.lang, id=m_id) }}{%- endmacro -%}
<li><a href="{{ meeting_url(208) }}">Meeting 208</a> - September 8, 2010</li>
<li><a href="{{ meeting_url(207) }}">Meeting 207</a> - February 10, 2009</li>
<li><a href="{{ meeting_url(206) }}">Meeting 206</a> - April 10, 2007</li>
<li><a href="{{ meeting_url(205) }}">Meeting 205</a> - April 3, 2007</li>
<li><a href="{{ meeting_url(204) }}">Meeting 204</a> - March 27, 2007</li>
<li><a href="{{ meeting_url(203) }}">Meeting 203</a> - March 20, 2007</li>
<li><a href="{{ meeting_url(202) }}">Meeting 202</a> - March 13, 2007</li>
<li><a href="{{ meeting_url(201) }}">Meeting 201</a> - February 20, 2007</li>
<li><a href="{{ meeting_url(200) }}">Meeting 200</a> - February 13, 2007</li>
<li><a href="{{ meeting_url(199) }}">Meeting 199</a> - February 6, 2007</li>
<li><a href="{{ meeting_url(198) }}">Meeting 198</a> - January 30, 2007</li>
<li><a href="{{ meeting_url(197) }}">Meeting 197</a> - January 16, 2007</li>
<li><a href="{{ meeting_url(196) }}">Meeting 196</a> - January 9, 2007</li>
<li><a href="{{ meeting_url(195) }}">Meeting 195</a> - January 2, 2007</li>
<li><a href="{{ meeting_url(194) }}">Meeting 194</a> - December 26, 2006</li>
<li><a href="{{ meeting_url(193) }}">Meeting 193</a> - December 12, 2006</li>
<li><a href="{{ meeting_url(192) }}">Meeting 192</a> - December 05, 2006</li>
<li><a href="{{ meeting_url(191) }}">Meeting 191</a> - November 28, 2006</li>
<li><a href="{{ meeting_url(190) }}">Meeting 190</a> - November 21, 2006</li>
<li><a href="{{ meeting_url(189) }}">Meeting 189</a> - November 14, 2006</li>
<li><a href="{{ meeting_url(188) }}">Meeting 188</a> - November 7, 2006</li>
<li><a href="{{ meeting_url(187) }}">Meeting 187</a> - October 31, 2006</li>
<li><a href="{{ meeting_url(186) }}">Meeting 186</a> - October 24, 2006</li>
<li><a href="{{ meeting_url(185) }}">Meeting 185</a> - October 17, 2006</li>
<li><a href="{{ meeting_url(184) }}">Meeting 184</a> - September 12, 2006</li>
<li><a href="{{ meeting_url(183) }}">Meeting 183</a> - August 1, 2006</li>
<li><a href="{{ meeting_url(182) }}">Meeting 182</a> - June 13, 2006</li>
<li><a href="{{ meeting_url(181) }}">Meeting 181</a> - May 30, 2006</li>
<li><a href="{{ meeting_url(180) }}">Meeting 180</a> - May 16, 2006</li>
<li><a href="{{ meeting_url(179) }}">Meeting 179</a> - May 9, 2006</li>
<li><a href="{{ meeting_url(178) }}">Meeting 178</a> - May 2, 2006</li>
<li><a href="{{ meeting_url(177) }}">Meeting 177</a> - April 25, 2006</li>
<li><a href="{{ meeting_url(176) }}">Meeting 176</a> - April 18, 2006</li>
<li><a href="{{ meeting_url(175) }}">Meeting 175</a> - April 4, 2006</li>
<li><a href="{{ meeting_url(174) }}">Meeting 174</a> - March 28, 2006</li>
<li><a href="{{ meeting_url(173) }}">Meeting 173</a> - March 21, 2006</li>
<li><a href="{{ meeting_url(172) }}">Meeting 172</a> - March 14, 2006</li>
<li><a href="{{ meeting_url(171) }}">Meeting 171</a> - March 7, 2006</li>
<li><a href="{{ meeting_url(170) }}">Meeting 170</a> - February 28, 2006</li>
<li><a href="{{ meeting_url(169) }}">Meeting 169</a> - February 21, 2006</li>
<li><a href="{{ meeting_url(168) }}">Meeting 168</a> - February 14, 2006</li>
<li><a href="{{ meeting_url(167) }}">Meeting 167</a> - February 7, 2006</li>
<li><a href="{{ meeting_url(166) }}">Meeting 166</a> - January 31, 2006</li>
<li><a href="{{ meeting_url(165) }}">Meeting 165</a> - January 24, 2006</li>
<li><a href="{{ meeting_url(164) }}">Meeting 164</a> - January 17, 2006</li>
<li><a href="{{ meeting_url(163) }}">Meeting 163</a> - January 10, 2006</li>
<li><a href="{{ meeting_url(162) }}">Meeting 162</a> - January 4, 2006</li>
<li><a href="{{ meeting_url(161) }}">Meeting 161</a> - December 20, 2005</li>
<li><a href="{{ meeting_url(160) }}">Meeting 160</a> - December 13, 2005</li>
<li><a href="{{ meeting_url(159) }}">Meeting 159</a> - December 6, 2005</li>
<li><a href="{{ meeting_url(158) }}">Meeting 158</a> - November 29, 2005</li>
<li><a href="{{ meeting_url(157) }}">Meeting 157</a> - November 22, 2005</li>
<li><a href="{{ meeting_url(156) }}">Meeting 156</a> - November 15, 2005</li>
<li><a href="{{ meeting_url(155) }}">Meeting 155</a> - November 8, 2005</li>
<li><a href="{{ meeting_url(154) }}">Meeting 154</a> - November 1, 2005</li>
<li><a href="{{ meeting_url(153) }}">Meeting 153</a> - October 25, 2005</li>
<li><a href="{{ meeting_url(152) }}">Meeting 152</a> - October 18, 2005</li>
<li><a href="{{ meeting_url(151) }}">Meeting 151</a> - October 11, 2005</li>
<li><a href="{{ meeting_url(150) }}">Meeting 150</a> - October 4, 2005</li>
<li><a href="{{ meeting_url(149) }}">Meeting 149</a> - September 27, 2005</li>
<li><a href="{{ meeting_url(148) }}">Meeting 148</a> - September 20, 2005</li>
<li><a href="{{ meeting_url(147) }}">Meeting 147</a> - September 13, 2005</li>
<li><a href="{{ meeting_url(146) }}">Meeting 146</a> - September 6, 2005</li>
<li><a href="{{ meeting_url(145) }}">Meeting 145</a> - August 30, 2005</li>
<li><a href="{{ meeting_url(144) }}">Meeting 144</a> - August 23, 2005</li>
<li><a href="{{ meeting_url(143) }}">Meeting 143</a> - August 16, 2005</li>
<li><a href="{{ meeting_url(142) }}">Meeting 142</a> - August 9, 2005</li>
<li><a href="{{ meeting_url(141) }}">Meeting 141</a> - August 2, 2005</li>
<li><a href="{{ meeting_url(140) }}">Meeting 140</a> - May 3, 2005</li>
<li><a href="{{ meeting_url(139) }}">Meeting 139</a> - April 26, 2005</li>
<li><a href="{{ meeting_url(138) }}">Meeting 138</a> - April 19, 2005</li>
<li><a href="{{ meeting_url(137) }}">Meeting 137</a> - April 12, 2005</li>
<li><a href="{{ meeting_url(136) }}">Meeting 136</a> - April 5, 2005</li>
<li><a href="{{ meeting_url(135) }}">Meeting 135</a> - March 28, 2005</li>
<li><a href="{{ meeting_url(134) }}">Meeting 134</a> - March 22, 2005</li>
<li><a href="{{ meeting_url(133) }}">Meeting 133</a> - March 15, 2005</li>
<li><a href="{{ meeting_url(132) }}">Meeting 132</a> - March 8, 2005</li>
<li><a href="{{ meeting_url(131) }}">Meeting 131</a> - March 1, 2005</li>
<li><a href="{{ meeting_url(130) }}">Meeting 130</a> - February 22, 2005</li>
<li><a href="{{ meeting_url(129) }}">Meeting 129</a> - February 15, 2005</li>
<li><a href="{{ meeting_url(128) }}">Meeting 128</a> - February 8, 2005</li>
<li><a href="{{ meeting_url(127) }}">Meeting 127</a> - February 1, 2005</li>
<li><a href="{{ meeting_url(126) }}">Meeting 126</a> - January 25, 2005</li>
<li><a href="{{ meeting_url(125) }}">Meeting 125</a> - January 18, 2005</li>
<li><a href="{{ meeting_url(124) }}">Meeting 124</a> - January 11, 2005</li>
<li><a href="{{ meeting_url(123) }}">Meeting 123</a> - January 4, 2005</li>
<li><a href="{{ meeting_url(122) }}">Meeting 122</a> - December 28, 2004</li>
<li><a href="{{ meeting_url(121) }}">Meeting 121</a> - December 21, 2004</li>
<li><a href="{{ meeting_url(120) }}">Meeting 120</a> - December 14, 2004</li>
<li><a href="{{ meeting_url(119) }}">Meeting 119</a> - December 7, 2004</li>
<li><a href="{{ meeting_url(118) }}">Meeting 118</a> - November 30, 2004</li>
<li><a href="{{ meeting_url(117) }}">Meeting 117</a> - November 23, 2004</li>
<li><a href="{{ meeting_url(116) }}">Meeting 116</a> - November 16, 2004</li>
<li><a href="{{ meeting_url(115) }}">Meeting 115</a> - November 9, 2004</li>
<li><a href="{{ meeting_url(114) }}">Meeting 114</a> - November 2, 2004</li>
<li><a href="{{ meeting_url(113) }}">Meeting 113</a> - October 26, 2004</li>
<li><a href="{{ meeting_url(112) }}">Meeting 112</a> - October 19, 2004</li>
<li><a href="{{ meeting_url(111) }}">Meeting 111</a> - October 12, 2004</li>
<li><a href="{{ meeting_url(110) }}">Meeting 110</a> - October 5, 2004</li>
<li><a href="{{ meeting_url(109) }}">Meeting 109</a> - September 28, 2004</li>
<li><a href="{{ meeting_url(108) }}">Meeting 108</a> - September 21, 2004</li>
<li><a href="{{ meeting_url(107) }}">Meeting 107</a> - September 14, 2004</li>
<li><a href="{{ meeting_url(106) }}">Meeting 106</a> - September 7, 2004</li>
<li><a href="{{ meeting_url(105) }}">Meeting 105</a> - August 31, 2004</li>
<li><a href="{{ meeting_url(104) }}">Meeting 104</a> - August 24, 2004</li>
<li><a href="{{ meeting_url(103) }}">Meeting 103</a> - August 17, 2004</li>
<li><a href="{{ meeting_url(102) }}">Meeting 102</a> - August 10, 2004</li>
<li><a href="{{ meeting_url(101) }}">Meeting 101</a> - August 3, 2004</li>
<li><a href="{{ meeting_url(100) }}">Meeting 100</a> - July 27, 2004</li>
<li><a href="{{ meeting_url(99) }}">Meeting 99</a> - July 20, 2004</li>
<li><a href="{{ meeting_url(95) }}">Meeting 95</a></li>
<li><a href="{{ meeting_url(93) }}">Meeting 93</a></li>
<li><a href="{{ meeting_url(92) }}">Meeting 92</a></li>
<li><a href="{{ meeting_url(90) }}">Meeting 90</a></li>
<li><a href="{{ meeting_url(82) }}">Meeting 82</a></li>
<li><a href="{{ meeting_url(81) }}">Meeting 81</a></li>
<li><a href="{{ meeting_url(80) }}">Meeting 80</a></li>
<li><a href="{{ meeting_url(79) }}">Meeting 79</a></li>
<li><a href="{{ meeting_url(78) }}">Meeting 78</a></li>
<li><a href="{{ meeting_url(77) }}">Meeting 77</a></li>
<li><a href="{{ meeting_url(76) }}">Meeting 76</a></li>
<li><a href="{{ meeting_url(75) }}">Meeting 75</a></li>
<li><a href="{{ meeting_url(74) }}">Meeting 74</a></li>
<li><a href="{{ meeting_url(73) }}">Meeting 73</a></li>
<li><a href="{{ meeting_url(72) }}">Meeting 72</a></li>
<li><a href="{{ meeting_url(71) }}">Meeting 71</a></li>
<li><a href="{{ meeting_url(70) }}">Meeting 70</a></li>
<li><a href="{{ meeting_url(69) }}">Meeting 69</a></li>
<li><a href="{{ meeting_url(68) }}">Meeting 68</a></li>
<li><a href="{{ meeting_url(66) }}">Meeting 66</a></li>
<li><a href="{{ meeting_url(65) }}">Meeting 65</a></li>
<li><a href="{{ meeting_url(64) }}">Meeting 64</a></li>
<li><a href="{{ meeting_url(63) }}">Meeting 63</a></li>
<li><a href="{{ meeting_url(62) }}">Meeting 62</a></li>
<li><a href="{{ meeting_url(61) }}">Meeting 61</a></li>
<li><a href="{{ meeting_url(60) }}">Meeting 60</a></li>
<li><a href="{{ meeting_url(59) }}">Meeting 59</a></li>
<li><a href="{{ meeting_url(58) }}">Meeting 58</a></li>
<li><a href="{{ meeting_url(57) }}">Meeting 57</a></li>
<li><a href="{{ meeting_url(56) }}">Meeting 56</a></li>
<li><a href="{{ meeting_url(55) }}">Meeting 55</a></li>
<li><a href="{{ meeting_url(54) }}">Meeting 54</a></li>
<li><a href="{{ meeting_url(53) }}">Meeting 53</a></li>
<li><a href="{{ meeting_url(52) }}">Meeting 52</a></li>
<li><a href="{{ meeting_url(51) }}">Meeting 51</a></li>
<li><a href="{{ meeting_url(50) }}">Meeting 50</a></li>
<li><a href="{{ meeting_url(49) }}">Meeting 49</a></li>
<li><a href="{{ meeting_url(47) }}">Meeting 47</a></li>
<li><a href="{{ meeting_url(35) }}">Meeting 35</a></li>
<li><a href="{{ meeting_url(34) }}">Meeting 34</a></li>
<li><a href="{{ meeting_url(33) }}">Meeting 33</a></li>
<li><a href="{{ meeting_url(32) }}">Meeting 32</a></li>
<li><a href="{{ meeting_url(31) }}">Meeting 31</a></li>
<li><a href="{{ meeting_url(30) }}">Meeting 30</a></li>
<li><a href="{{ meeting_url(29) }}">Meeting 29</a></li>
<li><a href="{{ meeting_url(28) }}">Meeting 28</a></li>
<li><a href="{{ meeting_url(26) }}">Meeting 26</a></li>
<li><a href="{{ meeting_url(25) }}">Meeting 25</a></li>
<li><a href="{{ meeting_url(23) }}">Meeting 23</a></li>
<li><a href="{{ meeting_url(22) }}">Meeting 22</a></li>
<li><a href="{{ meeting_url(21) }}">Meeting 21</a></li>
<li><a href="{{ meeting_url(20) }}">Meeting 20</a></li>
<li><a href="{{ meeting_url(18) }}">Meeting 18</a></li>
<li><a href="{{ meeting_url(15) }}">Meeting 15</a></li>
<li><a href="{{ meeting_url(12) }}">Meeting 12</a></li>
<li><a href="{{ meeting_url(11) }}">Meeting 11</a></li>
<li><a href="{{ meeting_url(10) }}">Meeting 10</a></li>
<li><a href="{{ meeting_url(9) }}">Meeting 9</a></li>
<li><a href="{{ meeting_url(8) }}">Meeting 8</a></li>
<li><a href="{{ meeting_url(7) }}">Meeting 7</a></li>
<li><a href="{{ meeting_url(4) }}">Meeting 4</a></li>
<li><a href="{{ meeting_url(3) }}">Meeting 3</a></li>
<li><a href="{{ meeting_url(2) }}">Meeting 2</a></li>
<li><a href="{{ meeting_url(1) }}">Meeting 1</a></li>
</ul>
{% endblock %}

15
i2p2www/pages/meetings/show.html Normal file
View File

@@ -0,0 +1,15 @@
{% extends "global/layout.html" %}
{% block title %}I2P Development Meeting {{ id }}{% endblock %}
{% block content %}
{% autoescape false %}
{% if header %}
{{ header | restructuredtext }}
{% endif %}
{% endautoescape %}
<div class="irclog">
<pre>
{{ log|escape }}
{# TODO: pygments #}
</pre>
</div>
{% endblock %}

5
i2p2www/pages/site/develop/api.html Normal file
View File

@@ -0,0 +1,5 @@
{% extends "global/layout.html" %}
{% block title %}API{% endblock %}
{% block content %}
See the <a href="{{ site_url('docs/how') }}">Index to Technical Documentation</a>.
{% endblock %}

526
i2p2www/pages/site/develop/applications.html Normal file
View File

@@ -0,0 +1,526 @@
{% extends "global/layout.html" %}
{% block title %}Application Development{% endblock %}
{% block content %}
<h1>Application Development Guide</h1>
<h2>Contents</h2>
<ul>
<li><a href="#why">Why write I2P-specific code?</a></li>
<li><a href="#concepts">Important concepts</a></li>
<li><a href="#options">Development options</a></li>
<li><a href="#start"><b>Start developing - a simple guide</b></a></li>
</ul>
<h2 id="why">Why write I2P-specific code?</h2>
<p>
There are multiple ways to use applications in I2P.
Using <a href="/i2ptunnel.html">I2PTunnel</a>,
you can use regular applications without needing to program explicit I2P support.
This is very effective for client-server scenario's,
where you need to connect to a single website.
You can simply create a tunnel using I2PTunnel to connect to that website, as shown in <a href="#tunnel.serverclient">Figure 1</a>.
</p>
<p>
If your application is distributed, it will require connections to a large amount of peers.
Using I2PTunnel, you will need to create a new tunnel for each peer you want to contact,
as shown in <a href="#tunnel.peertopeer">Figure 2</a>.
This process can of course be automated, but running a lot of I2PTunnel instances creates a large amount of overhead.
In addition, with many protocols you will need to force everyone to
use the same set of ports for all peers - e.g. if you want to reliably run DCC
chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port
10003 is Charlie, and so on, since the protocol includes TCP/IP specific information
(host and port).
</p>
<p>
General network applications often send a lot of additional data that could be used to identify users.
Hostnames, port numbers, time zones, character sets, etc. are often sent without informing the user.
As such, designing the network protocol specifically with anonymity in mind
can avoid compromising user identities.
</p>
<p>
There are also efficiency considerations to review when determining how to
interact on top of I2P. The streaming library and things built on top of it
operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP)
are strictly message based (like UDP or in some instances raw IP). The important
distinction is that with I2P, communication is operating over a long fat network -
each end to end message will have nontrivial latencies, but may contain payloads
of up to 32KB. An application that needs a simple request and response can get rid
of any state and drop the latency incurred by the startup and teardown handshakes
by using (best effort) datagrams without having to worry about MTU detection or
fragmentation of messages under 32KB.
</p>
<div class="box" id="tunnel.serverclient" style="text-align:center">
<img src="{{ url_for('static', filename='images/i2ptunnel_serverclient.png') }}" alt="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." title="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." />
<br /><br />
Figure 1: Creating a server-client connection using I2PTunnel only requires creating a single tunnel.
</div>
<br/>
<div class="box" id="tunnel.peertopeer" style="text-align:center">
<img src="{{ url_for('static', filename='images/i2ptunnel_peertopeer.png') }}" alt="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." title="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." />
<br /><br />
Figure 2: Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.
</div>
<br/>
In summary, a number of reasons to write I2P-specific code:
<ul>
<li>
Creating a large amount of I2PTunnel instances consumes a non-trivial amount of resources,
which is problematic for distributed applications (a new tunnel is required for each peer).
</li>
<li>
General network protocols often send a lot of additional data that can be used to identify users.
Programming specifically for I2P allows the creation of a network protocol
that does not leak such information, keeping users anonymous and secure.
</li>
<li>
Network protocols designed for use on the regular internet can be inefficient
on I2P, which is a network with a much higher latency.
</li>
</ul>
<p>
Applications written in Java and accessible/runnable
using an HTML interface via the standard webapps/app.war
may be considered for inclusion in the i2p distribution.
</p>
<h2 id="concepts">Important concepts</h2>
<p>There are a few changes that require adjusting to when using I2P:</p>
<h3>Destination ~= host+port</h3>
<p>An application running on I2P sends messages from and receives messages to a
unique cryptographically secure end point - a "destination". In TCP or UDP
terms, a destination could (largely) be considered the equivalent of a hostname
plus port number pair, though there are a few differences. </p>
<ul>
<li>An I2P destination itself is a cryptographic construct - all data sent to one is
encrypted as if there were universal deployment of IPsec with the (anonymized)
location of the end point signed as if there were universal deployment of DNSSEC. </li>
<li>I2P destinations are mobile identifiers - they can be moved from one I2P router
to another (or with some special software, it can even operate on multiple routers at
once). This is quite different from the TCP or UDP world where a single end point (port)
must stay on a single host.</li>
<li>
<p>
I2P destinations are ugly and large - behind the scenes, they contain a 2048bit ElGamal
public key for encryption, a 1024bit DSA public key for signing, and a variable size
certificate, which may contain proof of work or blinded data.
</p>
<p>
There are existing ways to refer to these large and ugly destinations by short
and pretty names (e.g. "irc.duck.i2p"), but at the moment those techniques do not guarantee
globally uniqueness (since they're stored locally at each person's machine as "hosts.txt")
and the current mechanism is not especially scalable nor secure (updates to one host file are
manually managed within Monotone, and as such, anyone with commit rights on the repository can
change the destinations). There may be some secure, human readable, scalable, and globally
unique, naming system some day, but applications shouldn't depend upon it being in place,
since there are those who don't think such a beast is possible.
<a href="naming.html">Further information on the naming system</a> is available.
</p>
</li>
</ul>
<h3>Anonymity and confidentiality</h3>
<p>A useful thing to remember is that I2P has transparent end to end encryption
and authentication for all data passed over the network - if Bob sends to Alice's destination,
only Alice's destination can receive it, and if Bob is using the datagrams or streaming
library, Alice knows for certain that Bob's destination is the one who sent the data. </p>
<p>Of course, another useful thing to remember is that I2P transparently anonymizes the
data sent between Alice and Bob, but it does nothing to anonymize the content of what they
send. For instance, if Alice sends Bob a form with her full name, government IDs, and
credit card numbers, there is nothing I2P can do. As such, protocols and applications should
keep in mind what information they are trying to protect and what information they are willing
to expose.</p>
<h3>I2P datagrams can be up to 32KB</h3>
<p>Applications that use I2P datagrams (either raw or repliable ones) can essentially be thought
of in terms of UDP - the datagrams are unordered, best effort, and connectionless - but unlike
UDP, applications don't need to worry about MTU detection and can simply fire off 32KB datagrams
(31KB when using the repliable kind). For many applications, 32KB of data is sufficient for an
entire request or response, allowing them to transparently operate in I2P as a UDP-like
application without having to write fragmentation, resends, etc.</p>
<h2 id="options">Development options</h2>
<p>There are several means of sending data over I2P, each with their own pros and cons.
The streaming lib is the recommended interface, used by the majority of I2P applications.
</p>
<h3>Streaming Lib</h3>
<p>
The <a href="streaming.html">full streaming library</a> is now the standard
interface. It allows programming using TCP-like sockets, as explained in the <a href="#start.streaming">Streaming development guide</a>.
</p>
<h3>BOB</h3>
<p>BOB is the <a href="BOB.html">Basic Open Bridge</a>,
allowing an application in any language to make streaming connections
to and from I2P. At this point in time it lacks UDP support, but UDP support
is planned in the near future. BOB also contains several tools, such as
destination key generation, and verification that an address conforms to
I2P specifications. Up to date info and applications that use BOB can be
found at this <a href="http://bob.i2p/">eepsite</a>.</p>
<h3>SAM, SAM V2, SAM V3</h3>
<p><i>SAM is not recommended. SAM V2 is okay, SAM V3 is beta.</i></p>
<p>SAM is the <a href="sam">Simple Anonymous Messaging</a> protocol, allowing an
application written in any language to talk to a SAM bridge through a plain TCP socket and have
that bridge multiplex all of its I2P traffic, transparently coordinating the encryption/decryption
and event based handling. SAM supports three styles of operation:</p>
<ul>
<li>streams, for when Alice and Bob want to send data to each other reliably and in order</li>
<li>repliable datagrams, for when Alice wants to send Bob a message that Bob can reply to</li>
<li>raw datagrams, for when Alice wants to squeeze the most bandwidth and performance as possible,
and Bob doesn't care whether the data's sender is authenticated or not (e.g. the data transferred
is self authenticating)</li>
</ul>
<p>SAM V3 aims at the same goal as SAM and SAM V2, but does not require
multiplexing/demultiplexing. Each I2P stream is handled by its own socket between the application
and the SAM bridge. Besides, datagrams can be sent and received by the application through datagram
communications with the SAM bridge.
</p>
<p>
<a href="samv2.html">SAM V2</a> is a new version used by imule
that fixes some of the problems in <a href="sam.html">SAM</a>.
<br />
<a href="samv3.html">SAM V3</a> is used by imule since version 1.4.0.
</p>
<h3>I2PTunnel</h3>
<p>The I2PTunnel application allows applications to build specific TCP-like tunnels to peers
by creating either I2PTunnel 'client' applications (which listen on a specific port and connect
to a specific I2P destination whenever a socket to that port is opened) or I2PTunnel 'server'
applications (which listen to a specific I2P destination and whenever it gets a new I2P
connection it outproxies to a specific TCP host/port). These streams are 8bit clean and are
authenticated and secured through the same streaming library that SAM uses, but there is a
nontrivial overhead involved with creating multiple unique I2PTunnel instances, since each have
their own unique I2P destination and their own set of tunnels, keys, etc.</p>
<h3>Ministreaming</h3>
<p><i>Not recommended</i></p>
<p>
It was possible to write I2P applications in Java using the ministreaming library.
However, the Streaming library has superceded this, and provides better functionality.
</p>
<h3>Datagrams</h3>
<p><i>Not recommended</i></p>
The <a href="datagrams">Datagram library</a> allows sending UDP-like packets.
It's possible to use:
<ul>
<li>Repliable datagrams</li>
<li>Raw datagrams</li>
</ul>
<h3>I2CP</h3>
<p><i>Not recommended</i></p>
<p><a href="i2cp">I2CP</a> itself is a language independent protocol, but to implement an I2CP library
in something other than Java there is a significant amount of code to be written (encryption routines,
object marshalling, asynchronous message handling, etc). While someone could write an I2CP library in
C or something else, it would most likely be more useful to use the C SAM library instead.
</p>
<h3>Web Applications</h3>
I2P comes with the Jetty webserver, and configuring to use the Apache server instead is straightforward.
Any standard web app technology should work.
<h2 id="start">Start developing - a simple guide</h2>
Developing using I2P requires a working I2P installation and a development environment of your own choice.
If you are using Java, you can start development with the <a href="#start.streaming">streaming library</a> or datagram library.
Using another programming language, SAM or BOB can be used.
<h3 id="start.streaming">Developing with the streaming library</h3>
Development using the streaming library requires the following libraries in your classpath:
<ul>
<li>$I2P/lib/streaming.jar: the streaming library itself.</li>
<li>$I2P/lib/mstreaming.jar: the ministreaming library is used as the base for the streaming library.</li>
<li>$I2P/lib/i2p.jar: some standard I2P classes (like the Destination class) are very convenient when developing.</li>
</ul>
<p>
Network communication requires the usage of I2P network sockets.
To demonstrate this, we will create an application where a client can send text messages to a server,
who will print the messages and send them back to the client. In other words, the server will function as an echo.
</p>
<p>
We will start by initializing the server application. This requires getting an I2PSocketManager
and creating an I2PServerSocket.
In addition, we will ask the I2PSocketManager for an I2PSession, so we can find out the Destination we use.
</p>
<div class="box">
<pre>
package i2p.echoserver;
import net.i2p.client.I2PSession;
import net.i2p.client.streaming.I2PServerSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
public class Main {
public static void main(String[] args) {
//Initialize application
I2PSocketManager manager = I2PSocketManagerFactory.createManager();
I2PServerSocket serverSocket = manager.getServerSocket();
I2PSession session = manager.getSession();
System.out.println(session.getMyDestination().toBase64()); //Print the base64 string, the regular string would look like garbage.
//The additional main method code comes here...
}
}
</pre>
<br /><br />
<p style="text-align:center">Code example 1: initializing the server application.</p>
</div>
<p>
Once we have an I2PServerSocket, we can create I2PSocket instances to accept connections from clients.
In this example, we will create a single I2PSocket instance, that can only handle one client at a time.
A real server would have to be able to handle multiple clients.
To do this, multiple I2PSocket instances would have to be created, each in separate threads.
Once we have created the I2PSocket instance, we read data, print it and send it back to the client.
The bold code is the new code we add.
</p>
<div class="box">
<pre>
package i2p.echoserver;
</pre>
<pre><b>
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.ConnectException;
import java.net.SocketTimeoutException;
import net.i2p.I2PException;
import net.i2p.client.streaming.I2PSocket;
import net.i2p.util.I2PThread;
</b></pre>
<pre>
import net.i2p.client.I2PSession;
import net.i2p.client.streaming.I2PServerSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
public class Main {
public static void main(String[] args) {
I2PSocketManager manager = I2PSocketManagerFactory.createManager();
I2PServerSocket serverSocket = manager.getServerSocket();
I2PSession session = manager.getSession();
System.out.println(session.getMyDestination().toBase64()); //Print the base64 string, the regular string would look like garbage.
</pre>
<pre><b>
//Create socket to handle clients
I2PThread t = new I2PThread(new ClientHandler(serverSocket));
t.setName("clienthandler1");
t.setDaemon(false);
t.start();
}
private static class ClientHandler implements Runnable {
public ClientHandler(I2PServerSocket socket) {
this.socket = socket;
}
public void run() {
while(true) {
try {
I2PSocket sock = this.socket.accept();
if(sock != null) {
BufferedReader br = new BufferedReader(new InputStreamReader(sock.getInputStream())); //Receive from clients
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(sock.getOutputStream())); //Send to clients
String line = br.readLine();
if(line != null) {
System.out.println("Received from client: " + line);
bw.write(line);
bw.flush(); //Flush to make sure everything got sent
}
sock.close();
}
} catch (I2PException ex) {
System.out.println("General I2P exception!");
} catch (ConnectException ex) {
System.out.println("Error connecting!");
} catch (SocketTimeoutException ex) {
System.out.println("Timeout!");
} catch (IOException ex) {
System.out.println("General read/write-exception!");
}
}
}
private I2PServerSocket socket;
}
}
</b></pre>
<br /><br />
<p style="text-align:center">Code example 2: accepting connections from clients and handling messages.</p>
</div>
When you run the above server code, it should print something like this (but without the line endings, it should just be
one huge block of characters):
<pre id="start.streaming.destination">
y17s~L3H9q5xuIyyynyWahAuj6Jeg5VC~Klu9YPquQvD4vlgzmxn4yy~5Z0zVvKJiS2Lk
poPIcB3r9EbFYkz1mzzE3RYY~XFyPTaFQY8omDv49nltI2VCQ5cx7gAt~y4LdWqkyk3au
6HdfYSLr45zxzWRGZnTXQay9HPuYcHysZHJP1lY28QsPz36DHr6IZ0vwMENQsnQ5rhq20
jkB3iheYJeuO7MpL~1xrjgKzteirkCNHvXN8PjxNmxe-pj3QgOiow-R9rEYKyPAyGd2pe
qMD-J12CGfB6MlnmH5qPHGdZ13bUuebHiyZ1jqSprWL-SVIPcynAxD2Uu85ynxnx31Fth
nxFMk07vvggBrLM2Sw82pxNjKDbtO8reawe3cyksIXBBkuobOZdyOxp3NT~x6aLOxwkEq
BOF6kbxV7NPRPnivbNekd1E1GUq08ltDPVMO1pKJuGMsFyZC4Q~osZ8nI59ryouXgn97Q
5ZDEO8-Iazx50~yUQTRgLMOTC5hqnAAAA
</pre>
This is the base64-representation of the server Destination. The client will need this string to reach the server.
<p>
Now, we will create the client application. Again, a number of steps are required for initialization.
Again, we will need to start by getting an I2PSocketManager.
We won't use an I2PSession and an I2PServerSocket this time.
Instead, we will use the server Destination string to start our connection.
We will ask the user for the Destination string, and create an I2PSocket using this string.
Once we have an I2PSocket, we can start sending and receiving data to and from the server.
</p>
<div class="box">
<pre>
package i2p.echoclient;
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.InterruptedIOException;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.net.ConnectException;
import java.net.NoRouteToHostException;
import java.util.logging.Level;
import java.util.logging.Logger;
import net.i2p.I2PException;
import net.i2p.client.streaming.I2PSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
import net.i2p.data.DataFormatException;
import net.i2p.data.Destination;
public class Main {
public static void main(String[] args) {
I2PSocketManager manager = I2PSocketManagerFactory.createManager();
System.out.println("Please enter a Destination:");
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String destinationString = null;
try {
destinationString = br.readLine();
} catch (IOException ex) {
System.out.println("Failed to get a Destination string.");
return;
}
Destination destination = null;
try {
destination = new Destination(destinationString);
} catch (DataFormatException ex) {
System.out.println("Destination string incorrectly formatted.");
return;
}
I2PSocket socket = null;
try {
socket = manager.connect(destination);
} catch (I2PException ex) {
System.out.println("General I2P exception occurred!");
} catch (ConnectException ex) {
System.out.println("Failed to connect!");
} catch (NoRouteToHostException ex) {
System.out.println("Couldn't find host!");
} catch (InterruptedIOException ex) {
System.out.println("Sending/receiving was interrupted!");
}
try {
//Write to server
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
bw.write("Hello I2P!\n");
bw.flush(); //Flush to make sure everything got sent
//Read from server
BufferedReader br2 = new BufferedReader(new InputStreamReader(socket.getInputStream()));
String s = null;
while ((s = br2.readLine()) != null) {
System.out.println("Received from server: " + s);
}
socket.close();
} catch (IOException ex) {
System.out.println("Error occurred while sending/receiving!");
}
}
}
</pre>
<br /><br />
<p style="text-align:center">Code example 3: starting the client and connecting it to the server application.</p>
</div>
<p>
Finally, you can run both the server and the client application.
First, start the server application. It will print a Destination string (like shown <a href="#start.streaming.destination">above</a>).
Next, start the client application. When it requests a Destination string, you can enter the string printed by the server.
The client will then send 'Hello I2P!' (along with a newline) to the server, who will print the message and send it back to the client.
</p>
<p>
Congratulations, you have successfully communicated over I2P!
</p>
<h2>Existing Applications in Development</h2>
Contact us if you would like to help.
<ul>
<li>
<a href="http://i2pbote.i2p/">I2P-Bote</a> - contact HungryHobo
</li><li>
<a href="http://syndie.i2p2.de/">Syndie</a>
</li><li>
<a href="http://www.imule.i2p/">IMule</a>
</li><li>
<a href="http://forum.i2p/viewforum.php?f=25">I2Phex</a> - contact Complication
<a href="http://forum.i2p2.de/viewforum.php?f=25">(outside I2P)</a>
</li><li>I2PRufus - contact codevoid
</li><li>I2P-BT - contact sponge
</li><li><a href="http://bob.i2p">BOB</a> - contact sponge
</li></ul>
<h2>Application Ideas</h2>
<ul>
<li>NNTP server - there have been some in the past, none at the moment
</li><li>Jabber server - there have been some in the past, and there is one at the moment, with access to the public internet
</li><li>PGP Key server and/or proxy
</li><li>Download manager / eepget scheduler -
We use eepget to fetch lots of things reliably over i2p, and there's already an
implementation of a sequential download manager (net.i2p.util.EepGetScheduler),
but there isn't any sort of user interface to it. A web based UI would be
great.
</li><li>Content Distribution / DHT applications - help out with <a href="http://feedspace.i2p/">feedspace</a>,
port dijjer, look for alternatives
</li><li>Help out with <a href="http://syndie.i2p2.de/">Syndie</a> development
</li><li>Web-based applications - The sky is the limit for hosting web-server-based
applications such as blogs, pastebins, storage, tracking, feeds, etc.
Any web or CGI technology such as Perl, PHP, Python, or Ruby will work.
</li><li>Resurrect some old apps - in the i2p source package -
bogobot, pants, proxyscript, q, stasher, socks proxy, i2ping
</li></ul>
{% endblock %}

715
i2p2www/pages/site/develop/license-agreements.html Normal file
View File

@@ -0,0 +1,715 @@
{% extends "global/layout.html" %}
{% block title %}License Agreements{% endblock %}
{% block content %}
<p>For more information see <a href="{{ site_url('develop/licenses') }}">licenses.html</a>.
</p><p>Following is a monotonerc file defining the current trust list.
Developers must use this file in ~/.monotone/monotonerc or
_MTN/montonerc in their i2p.i2p workspace.
<pre>
function intersection(a,b)
local s={}
local t={}
for k,v in pairs(a) do s[v.name] = 1 end
for k,v in pairs(b) do if s[v] ~= nil then table.insert(t,v) end end
return t
end
function get_revision_cert_trust(signers, id, name, val)
local trusted_signers = { "complication@mail.i2p", "zzz@mail.i2p", "dev@welterde.de",
"Oldaris@mail.i2p", "sponge@mail.i2p", "dream@mail.i2p", "mathiasdm@mail.i2p",
"mkvore-commit@mail.i2p", "z3d@mail.i2p", "cervantes@mail.i2p", "BlubMail@mail.i2p",
"walking@mail.i2p", "neutron@mail.i2p", "HungryHobo@mail.i2p", "russiansponsor@mail.i2p",
"echelon@mail.i2p", "forget@mail.i2p", "privateer@mail.i2p", "duck@mail.i2p",
"m1xxy@mail.i2p", "hiddenz@mail.i2p", "dev@robertfoss.se", "hamada@mail.i2p",
"magma@mail.i2p", "kytv@mail.i2p", "str4d@mail.i2p", "meeh@mail.i2p" }
local t = intersection(signers, trusted_signers)
if t == nil then return false end
if table.getn(t) >= 1 then return true end
return false
end
</pre>
</p><p>Agreements:
<pre>
Complication:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHyXwu+h38a3n8zjMRAjeSAJ9MFx/ENbUu8+3/U7KTj+FGL/NkHQCdE38G
IWV1Gaqcis9sFEW7Nh0hY+c=
=WPeP
-----END PGP SIGNATURE-----
zzz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I affirm that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHyaYXQVV2uqduC+0RAhn4AJ40JO/ep1JhmghjPU/IeISIa2fY8ACgiuV0
vOCHNLZ8kiXKc8cTzYHGnU0=
=ZzDd
-----END PGP SIGNATURE-----
welterde:
Received by zzz 2008-02-16, need to put clearsigned version here.
Oldaris:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
Oldaris, 2008.07.15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIfQjqzZzOariGyHgRAgR3AKCBFidvx7u1xp1UcNPZSX4VcHMQmwCg0zos
IfrFyqSeeuhGoGVoq8godnY=
=GSEI
-----END PGP SIGNATURE-----
Sponge:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code they commit under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iJwEAQECAAYFAkjc2NsACgkQEGXqrGArRL24pQQAheyOBJiLU4wtbXFL5kVny3PZ
W8syAlzBC4sbOm3PkG9YLWh38Lnl+JPvVklRHJbpjRLEfwx6VwEiJRfZB6u+X7x/
qRwzjH6HYjz+tX3OAcj0MYH7yr09DLaJ26171X08BXoNpYuu4WWkXx8QnfgvZKVF
TeTxhTBL/iWBPKCF2Tk=
=+5bk
-----END PGP SIGNATURE-----
Dream:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmDVuwACgkQ9BQnlhdx/DlVugCePaRdhpg3qiOyQ71HeiGxT528
RmsAoLyxOkGxHn9FO+BGMabzeLAq2vV3
=Cqfg
-----END PGP SIGNATURE-----
MOSFET:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to any code I contribute to the I2P and Syndie projects,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmFAWcACgkQZ6SDODlcTO04JgCdGy4duWKRaTWkEdq8GW1ukOkU
+YAAn1Ch68XJZqLfXqJU3igcRjWbapD1
=64sn
-----END PGP SIGNATURE-----
mkvore:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAknVxdQACgkQUbTVRUoTVGhKUQCfWs3bw+fo0wqbKcURotncsfsA
uJgAnjnImkb5iEDp5vCccQO4PDGYp2+u
=0iW6
-----END PGP SIGNATURE-----
Mathiasdm:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknYaiwACgkQSgosdkktX9aE1gCgsQhfzyHhSLWrRsDfCz+HaITD
ApkAn2RjN+wpldf52Ur2nTVSvpLiHcik
=Znrk
-----END PGP SIGNATURE-----
dr|z3d:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I, dr|z3d, do solemnly agree that, in respect of the Invisible Internet Project (I2P):
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkpN+Q4ACgkQ00a8KJajPMJdjQCfWBovGyOKbZkvL47+FNX5s+14
f3QAnAkcOZYQ6rbPG8N8orH7+BMGvfPf
=UxMM
-----END PGP SIGNATURE-----
cervantes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkpa5VUACgkQxQxxfQtaKXwKcwCgm8yLYdv+VtjS+1P89U4zQxL4
IowAoIghIIWdMs3oMJpGAXfXTqpjRwXJ
=lNJP
-----END PGP SIGNATURE-----
blub (BlubMail@mail.i2p):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
1. Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
2. If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
3. I have the right to release the code I commit under the terms I am committing it
One warning about 3:
German law applies for me and in german law the concept of "public domain" doesn't exist. Its also not possible to waive all rights to the extent the "public domain" concept (as understood in the US) requires (for the ones speaking german: see for example http://de.wikipedia.org/wiki/Public_domain and http://dejure.org/gesetze/UrhG/29.html). IANAL, but I would guess that this is relevant when I commit code, even if I2P isn't a german project.
I don't really care about legal issues but since the whole point of me signing this seems to be avoiding legal issues and/or uncertainty which code has which license and similiar issues, I thought I should say this. If you don't care, ignore it. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqjRpgACgkQD9YhRSUxPSd74wCdEIHUauSInrfmhXlcx3t5pwrh
9RQAoNy6BW1qSSGhu+Jd2EQ8fQOoO13q
=LG0S
-----END PGP SIGNATURE-----
walking:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I agree that, in respect of the Invisible Internet Project (I2P):
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
iQEcBAEBAgAGBQJK3xwEAAoJELST8RRG8p88DQsH/2cMRMtDiaYKNF+fQvdSKuQI
igqRJnnIr/g5s8alfikRhm6MqR/q/vsWVfQlKs+KwL+15OKPjJJtxahp/CsWu5ZX
edHZv4nKGuSB7FvUoy0Lz6LRlu0HgZl7nli6YNVYbfbAQ1QbPY3wbvRxkLyHy1Zm
kB1XyfzOvA9gpu6r3NLUR8a5mhDUbOtNR8IxoNC/Z1ogsf1c5kzbz0ncHPiV1wMx
WZYIJ6vaa0BzJcEi2BDQWsPasEoMlGiK1+WXrjTq4lYcJYu+xrNFh+ofbRYqYhaf
3sGSCgK6abMlQeoO1aO5uo6CRI/Yvrfp5G5y7S/yDOq03glK3RnPAYlmc3s6VLY=
=i/D9
-----END PGP SIGNATURE-----
neutron:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi zzz,
I agree to the following :
- - Unless marked otherwise, all code I commit is implicitly licensed
under the component's primary license
- - If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
- - I have the right to release the code they commit under the terms I
am committing it
Neutron
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkr3D7MACgkQDkulOvK9/Uww+ACeJ/ILV87A7AtRqJI78MutKlxr
IpYAn0MXlHOB9aA7aR07Kj95pvF8A6wv
=AUjh
-----END PGP SIGNATURE-----
HungryHobo:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it.
HungryHobo, 11-3-2009
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkrxDEMACgkQHix7YXbc3BL+GACdGH9r4WWqnZS4ZHdvhq2kEgEH
FQYAn3gMHNDEBh6YD8KBK4UT/v89PRmy
=EXov
-----END PGP SIGNATURE-----
russiansponsor:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksZr28ACgkQg9RXHZerbBDNqACfa1EHKmqFbX0F3MOaAqln9NMX
JcYAn2dmuA6/jdJW7VikLQbNrKasqG6a
=WsTC
-----END PGP SIGNATURE-----
echelon:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksaywwACgkQXE9k4qzN3VNuIwCcDR2NL7aVAs+DftvFkoqy9Bnx
7zUAn3PYwfChW0MYdX2EsxV/DCHgk7y0
=HEKB
-----END PGP SIGNATURE-----
4get:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit is implicitly licensed
under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am
committing it
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkseTgMACgkQSH2S/jaH2VEYeACgsPSxEXAxWfyQ3/qNpJhbBTlh
Q/QAn3tS6UisuXPCFDh9N4BxcscjSD+5
=6DAb
-----END PGP SIGNATURE-----
duck:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit is implicitly licensed
under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am
committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkulRM8ACgkQHV6vOQfY4WwZswCfTjd7ktLjgqXPL7gvt6z2dxTQ
aFAAoJn1aPHVbMw/9FmkTmPSruVFs8V1
=bgCE
-----END PGP SIGNATURE-----
privateer:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkwKdKoACgkQTo2HeGooF8zClwCfVh8uaCHNP4MQwrB1egFKO40j
aqEAn3zAoSf0hCbTU/A489RKeQ6DA6GM
=mA0j
-----END PGP SIGNATURE-----
m1xxy:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I, mixxy/m1xxy, hereby state that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it.
* The following is my monotone signing key:
c9b970f5e8917eada663d4c6b22096617021c95c m1xxy@mail.i2p
[pubkey m1xxy@mail.i2p]
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/aaFUq37RQdJpMC8aacqYLdd88wNVjwI+4HY5d7a61HvYIAecg1KJlq/CDFFrygmCcusnFaBmmBQFLO+gJXPKi9PMo1vaENiqCTVfY4EUpMMYzpuqKMKjyfuT6eoOHCZEKfZosUowyJt61FsTzGu+B9y27d0jxXwXT/fml100EwIDAQAB
[end]
mixxy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJM1gjUAAoJECDrk8/2C++w+WwP/1GLBHpTGYiDO/zfqECgVRu2
S+qxTdEWcJyfz1MY8tJ9vMIhlr66jxveI1KZ4sNUln91yPR2KDgMrBa31wL8IHAz
T4uj7paMt8zLtptMbn2nGqdl/X3fmGloDQvW/VB0MWj3YpBgxXiMfEf3Mv9BcnV4
B6IUvnXAWVe86Dlon1KLoQjAB3hjiGZV0vUV8sjEOYxX/qztLAfP1FPHCRdKlNYY
hb2zNdRTHlCF+CKdZ+TX4HB7qlsjYUbhRJhh2pN2Rwz/2w/CddwXQ4jaKjCkn5T9
D5Ekz4/b68doGq1hhjTf/GZ1FqVt+gkYr8MYPGZP5oJ6O4X5yPc3QhRy5cMlERSj
S5+lXB/nM09w5bScHtdfHauxUI/vWOdF78BzCJHhOBBHZ/jrsV2iX6QDaf+X/FbT
64SWXTa4jzQeE7MafF9Bkex1rWGJiom5Ew4NG73e1GyGtkwvRV6j5H3AKvpgRJzG
G7W3/7MSZjNP7aIs2+BqYe9YveV0GCzC0l0lhIHvKNzRv6Avvvx7krORMQZqSt1k
lVPIAUyoW+ScB+E26dVpRFne/0q9yUcQOeKyqehGCEFtgqQCqLsdTHynxayp58bJ
lccrgLY+pzPpNg5w/5kJFm70ih9MOHRdRik9TiGvj56tzLUEPrD7WeMzl4mkeg0Y
2WPghzlpoV5C1SJkv+dR
=YLVN
-----END PGP SIGNATURE-----
hiddenz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I, hiddenz/anon8373/slow, hereby state that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it.
* The following is my monotone signing key:
[pubkey hiddenz@mail.i2p]
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnpEeIignM2UUsJT9+hSMcVOUuf0PZTxi9G3zRhDjal8Qdy/NUZQELAc6/gBhnZcSP4BHp/0BTTxXthlTjko8nkwx+EgzQO425Vgb1v/7RneCqEDjMP6QyZUOn1Hi2UBw+jvnbjFk1wDqt9BPdAKITfp3l7bR1xGr4gs1M4MSrcwIDAQAB
[end]
hiddenz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJM3u7uAAoJEFp3lNknxN+16HoIAMNYVELPBHOM4iqO1lWeFqmK
mSw/+eME05KvboZUq9SsJjInUkxlbfDWHf/DuUlCnTPePuQY+wTQPOa18ncldG0y
bgO71WnCSyIydrw8dIUtMBfvVzcSP4c5h0ty10Dw+YxdKL2TLTIw4JuqYCPhE4cm
1IqBfHT5or7A2ahCXLkUt2YX9NW9SAl8xUs+/g5rzc42EAgh656JK83G7kA38UID
nn6ZA+A/3hrTe1+lJ0yHa6sCnJGJ6+tdJlLzjeU6K34cRPCcn2sPO9LUlM6VHVga
AkTEFPvxhJC9yJ4cgIJ5AlrcF8B4Ufb0gsfsEfebAl1puA0C/MRxywTSjZTTB3k=
=UDcv
hottuna:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hottuna:
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit
is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit
under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)
iQGcBAEBAgAGBQJNKd3GAAoJEBVx72WXYlXhZjEL/3miyEMtggiJF73UJ26qLyAp
9vFqoztcCHZTdDS3jpXaDY3v2WnfT6bB3eQjrFYkwDO8UpVqjdCnPUhs/sqHg0eX
eqesy6IqDhluxJTO3vlvgBJVh449/g1P15hOQ1aR3vv12okmv85yOD7qbprkAZ9P
J2uByT2L1EaLUuYVABVkmoZyBhvmSFZkfvXmToYlywo413r36mW4M+Y7yFkBuw0x
aEvZ43zVVDaMsJQwTPdcUb4RmfSPk8d15FOr9WbWzSfKhUZ1HUtCWjPUuYWPzIrg
APnJswb07ekm8G9bPeKctOg8lJnJTbM0HzA1KGaCzvpJ+asz6HY8+2mq5RzvQ5XX
+6x+heNjNNG6f55cdwTw+ivWcsZiKDliAMUWlSkHMoWLjdzYOzrCM0vNf+BQMYeU
+Qg/bOU4Pt11Hfn5/PwY7zdK3KTp/bqtWE6kBdlFXtnPdZKaYtUTmwdCgB/2EC2T
pJOW/MBcMyHC5MxdistNFpXDv4O8dt7SNe83ADB2bA==
=aXNE
-----END PGP SIGNATURE-----
hamada:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hamada affirm that:
* Unless marked otherwise, all code I commit is implicitly
licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed
under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I
am committing it
Hamada
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJNUs9+AAoJEOEGJ9ydVi3DddMH/0Bl4Mh3oSWFfx8peOj2JG2z
bXHrK7kDHSK+aJrcFORQ4YPg2INjCH5GDDxaALhHKnVpTqZHy2F+RWII1SYVnU6l
SQKBKOKw4bHQZSS0ibdsRkUbP1cyoxR9bh0SXfDFjwLu3rzsU4FFc6vmRAIdwiOo
xQK3RpiPpzegsZPOFr4+vHIJUGcgGce86EIjC5VSoQHb3gHXsnsYGYBIszEj1MZ4
OCzbjV7Gl44sZ6R8Q2AU1Dita7ANJv6bkbk8W8Rurxqi2lUDHiWkW2XaoZ18mvnj
dZ65tC2kHgJHVU0oIn5rGMA7uuQizFL0d6pzQfJgw1hMA29sGQmxovy+Bp85Pqk=
=HeGr
-----END PGP SIGNATURE-----
magma:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I affirm that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iQIcBAEBAgAGBQJNg8FwAAoJEKiufQgd4cCY8sEP/13U7rmFMyYgbITiJHxRM/Kl
BFW/iVYPqF4Kr9qjT0S80kOw0wvHctWGPAoHv23YxUYRrJuW0gd5EAdv+1KQBmE/
lpKaTXMAt8DKba80dRk5I1S6SnJhAKyesF+nlxi53EfqIp1mRwSwzzRWgx9mz08R
jJSyEbPHX/ipwmohEAZ1diIYQv9QFjrrXOv+avFZgm56tj3ckBtKZNuZ+P/0sttJ
zmom7H7v9O1WlHiF50TuiLRM8V4XMKRRFw2GHaUgC/Uh5jN6PHEBoeQT5ssXvVIu
7IcCx9wTmABoGo2PALO51C+2aMvDXFml7QCEjwKtG2zelWJLXR1tyZuQdn+fxLa0
CDLc/V4mSgjscNN9gOJwX8AIUqwzA/SalZ5ng6gs6IqHk6wnrznw5kKNsEi1FInI
n2MlDsgCiv1D6gqqOYEJYrWYmQqOoU7fNi/cgi9vJ1XQOA0pd40SeoNMNzs4LmIu
oPifPJ+ODqfxTeBGSAZ3UDDdv80hzFlhMXHKk/a0+CpsBd1OmIkE+YhCQTI23wfv
xBzzO3WoecufpM1Ykg0yOYlGJ3IMJ1n7zvobJfiExeLDBM7fPFmJqB1sFRyV0n9f
sNMV1SjtLKZr65oePxFL1ludkQ6aMqlLCzNOSec6cUUSnkd+YwieT5yFpOXb6d8a
w4O9LtQO1R4tgrVXhBw4
=j/xY
-----END PGP SIGNATURE-----
kytv:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I KillYourTV/KYTV affirm that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
[pubkey kytv@mail.i2p]
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMMTHQs4AQ0KuXjHsPRvfeBo2EydIAcGcBH7VCO26AofX2ns3ezTKfvmv6QcFhcxn41I6OdG29DdFVRz4D8hIZvOoFYfe87nswgyXW85rEilJP02Z8HCr/dcYJbPsWAlMr7/UIDsT/9swd0U6QTf9X2W+VORyhDdYXcG8zikBqXQIDAQAB
[end]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJN0b3UAAoJEKvgwxnfCgoaQaMH/RdNoOt+1lm4cztvv5f2QBL3
W4h3PjloDqkLE4ATDm+AcctahQaWuA221AMOrhR0aS+93wm+mOxzSmeoE91V475n
2fpC/zWx0WRAzjQkr1M6OkcXNy6f+H5/UkBcaivzI9y5wUv5ETUHwiy+5qzG4oQ7
AzbPHeJic88c6dyGX6rwa5VFMXLKYnr7h/i562/Ynaqus8tu/td1KEGkdNFgW4We
y/aXYqaNYtds4xova49m99Y5u1kfKltv4YVEwY5a7Cj8p/31aeD8c10rWrf00R9H
XlL2/b0lIx1C8CAK5TmdrD8G1SXl614SJTGuQfBT2N6yCT+jcrOMJIghCZhvmLQ=
=U1Tw
-----END PGP SIGNATURE-----
str4d:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I str4d affirm that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license.
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses.
* I have the right to release the code I commit under the terms I am committing it.
* The following is my monotone signing key:
01265f0c817b24548478341fb75e672720a78b21 str4d@mail.i2p
[pubkey str4d@mail.i2p]
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDe4zkWVW8fBXGtnMpWbw316qbxWhKdnM86bnPyU3a8C2ERaofESzoZPXm21BR4jEqHLFzVzni4MTAJ+J0XjW70Le5DZTm/AG18qXd8UsK2+IreCHqnv5XPL8Lw8oY6zNoT834emGqH2n0T98OHF6zNUStBrvuv9AFPa6FZocF2mwIDAQAB
[end]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJPE5faAAoJENXeOJaUpGWy5kUIAIhe1ow0VpMgJitkBr8cBF8B
iJoKJ/DrCQ+XGk8API05VpyW0BLnG9qVRZh8DZux3NealIk3k37gN5rVHas0vpjU
5qzqFNwpeyPSSFhylLMqf3fYdjJJZieZfWU/XW7HUMYGgZ03Lq95sxPRPyl8A0D8
2ahv537Vy4EOZCdE8CvBgS/Hk0TVrG9EPL/vR1T6cx9YSV5/R0xiNNKujgoUHurX
8gHudomaEf+VxqDFCFQbjIWqDuf1sm1eRQokvO+wELqNjkUsWhDMAS54EjTmYN+h
Zc8XFXkeLUdRU6zJHo0tRWo0zswIW+a0r5W+T5MHwUnYOiTUUVgOjtwTGN7uURQ=
=nEwG
-----END PGP SIGNATURE-----
meeh:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Applicable to the code I contribute to the I2P project,
I hereby state that:
* Unless marked otherwise, all code I commit is implicitly licensed under the component's primary license
* If specified in the source, the code may be explicitly licensed under one of the component's alternate licenses
* I have the right to release the code I commit under the terms I am committing it
Meeh, 9 Aug 2012
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJQJC9mAAoJELj1P6o1Twr4+i0QANHrOH8CyUJHVXkbTAxRdKW0
u4avJvhQchyXjGvEPxYzUbQw2th41XlaNVKXgoiWTMKdOc88kkhL9dHj8yasMIHI
hncureihJ7bFS11IFBauqP8nV8UG3oONq9GqzW+6YxQ4SL6UAMP84iXCfB6W0wBd
ZE/06i5ezdsbeGfIgbrgkNsQMVcGRrbV5S3kBbW+lV4RitEsF2qb2IYlwbSUUSL9
/7/8FX87xocLRs3GOjhmRiyifMSoSRShnmMmckDNGlkY3Yz19HSThE47xnyg9Aaj
NYzmZMJFVnY6Rt1d4iLEw+/DUlYqs0afovHT2MnqymuN89204I6Yccn3n6AGKJxx
yJX6U4x49BwohG7ZW1S9RINoobqcg3l1Ne1Lp5EBe8jyxFjz0n1684biDuyKJx/o
ryp8mJ2cRKEWOduAyIChMeo/tFaDkMg/tTyuLrpSw404XpXa4EaUUlbZVQRHf25g
1Kil1XL+KhFcAP3hgjmpfc2ukFcL6j09yI0eZhlkJLosI+lKMpK3dqcjbdOiOauk
vQlJdkYZyxW2AReymH2XDI+cDg8tRw9iU22rAABXFs8zy5brK2Gjn1DK/sEVIdna
NVr7aW4hiQWqHVWivVy5Otf8Ioacoi8i2NISZtbCc68WtEkoFmEdW7QB+kwSsXIq
R2VFZ/114yCNY74KmujA
=jfFH
-----END PGP SIGNATURE-----
</pre>
{% endblock %}

311
i2p2www/pages/site/develop/licenses.html Normal file
View File

@@ -0,0 +1,311 @@
{% extends "global/layout.html" %}
{% block title %}Licenses{% endblock %}
{% block content %}
<h1>I2P Software Licenses</h1>
<p>
As required by our
<a href="{{ site_url('docs/how/threatmodel') }}">threat model</a> (among other reasons), the
software developed to support the anonymous communication
network we call I2P must be freely available, open source,
and user modifiable. To meet these criteria, we make use of
a variety of legal and software engineering techniques so
as to remove as many barriers to entry for those considering
making use of or contributing to the I2P effort.</p>
<p>While the information below may be more confusing than just simply
stating "I2P is BSD", "I2P is GPL", or "I2P is public domain",
the short answer to the question "How is I2P licensed?" is this:</p>
<h2>All software bundled in the I2P distributions will allow:</h2>
<ol>
<li>use without fee</li>
<li>use with no restrictions on how, when, where, why, or by whom is running it</li>
<li>access to the source code without fee</li>
<li>modifications to the source</li>
</ol>
<p>Most of the software guarantees much more - the ability of <b>anyone</b> to
distribute the modified source however they choose. However, not all of the
software bundled provides this freedom - the GPL restricts the ability of
developers who wish to integrate I2P with their own applications that are not
themselves open source applications. While we applaud the noble goals of
increasing the resources in the commons, I2P is best served by removing any
barriers that stand in the way of its adoption - if a developer considering whether
they can integrate I2P with their application has to stop and check with their lawyer,
or conduct a code audit to make sure their own source can be released as GPL-compatible,
we lose out.</p>
<h2>Component licenses</h2>
<p>The I2P distribution contains several resources, reflecting the partitioning of
the source code into components. Each component has its own license, which all
developers who contribute to it agree to - either by explicitly declaring the release
of code committed under a license compatible with that component, or by implicitly
releasing the code committed under the component's primary license. Each of these
components has a lead developer who has the final say as to what license is compatible
with the component's primary license, and the I2P project manager has the final say as
to what licenses meet the above four guarantees for inclusion in the I2P distribution.</p>
<table border="1">
<tr>
<td valign="top" align="left"><b>Component</b></td>
<td valign="top" align="left"><b>Source path</b></td>
<td valign="top" align="left"><b>Resource</b></td>
<td valign="top" align="left"><b>Primary license</b></td>
<td valign="top" align="left"><b>Alternate licenses</b></td>
<td valign="top" align="left"><b>Lead developer</b></td>
</tr>
<tr>
<td valign="top" align="left"><b>I2P SDK</b></td>
<td valign="top" align="left">core</td>
<td valign="top" align="left">i2p.jar</td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a></td>
<td valign="top" align="left">
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">zzz</td>
</tr>
<tr>
<td valign="top" align="left"><b>I2P Router</b></td>
<td valign="top" align="left">router</td>
<td valign="top" align="left">router.jar</td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a></td>
<td valign="top" align="left">
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">zzz</td>
</tr>
<tr>
<td valign="top" align="left"><b>Ministreaming</b></td>
<td valign="top" align="left">apps/ministreaming</td>
<td valign="top" align="left">mstreaming.jar</td>
<td valign="top" align="left">
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a></td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">mihi</td>
</tr>
<tr>
<td valign="top" align="left"><b>Streaming</b></td>
<td valign="top" align="left">apps/streaming</td>
<td valign="top" align="left">streaming.jar</td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a></td>
<td valign="top" align="left">
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">zzz</td>
</tr>
<tr>
<td valign="top" align="left"><b>I2PTunnel</b></td>
<td valign="top" align="left">apps/i2ptunnel</td>
<td valign="top" align="left">i2ptunnel.jar</td>
<td valign="top" align="left">
<a href="#java_exception">GPL + exception</a></td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a><br />
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">mihi</td>
</tr>
<tr>
<td valign="top" align="left"><b>HTTPTunnel</b></td>
<td valign="top" align="left">apps/httptunnel</td>
<td valign="top" align="left">httptunnel.jar</td>
<td valign="top" align="left">
<a href="#java_exception">GPL + exception</a></td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a><br />
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">mihi</td>
</tr>
<tr>
<td valign="top" align="left"><b><a href="sam">SAM</a> Bridge</b></td>
<td valign="top" align="left">apps/sam</td>
<td valign="top" align="left">sam.jar</td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a></td>
<td valign="top" align="left">
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">human</td>
</tr>
<tr>
<td valign="top" align="left"><b><a href="sam">SAM</a> perl library</b></td>
<td valign="top" align="left">apps/sam/perl</td>
<td valign="top" align="left">SAM.pm</td>
<td valign="top" align="left">
<a href="http://www.perl.com/pub/a/language/misc/Artistic.html">Artistic</a></td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">BrianR</td>
</tr>
<tr>
<td valign="top" align="left"><b><a href="sam">SAM</a> C library</b></td>
<td valign="top" align="left">apps/sam/c</td>
<td valign="top" align="left">libSAM</td>
<td valign="top" align="left">
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a></td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">Nightblade</td>
</tr>
<tr>
<td valign="top" align="left"><b><a href="sam">SAM</a> Python library</b></td>
<td valign="top" align="left">apps/sam/python</td>
<td valign="top" align="left">i2p.py</td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a></td>
<td valign="top" align="left">
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">Connelly</td>
</tr>
<tr>
<td valign="top" align="left"><b><a href="sam">SAM</a> C# library</b></td>
<td valign="top" align="left">apps/sam/csharp/</td>
<td valign="top" align="left">n/a</td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a></td>
<td valign="top" align="left">
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">smeghead</td>
</tr>
<tr>
<td valign="top" align="left"><b>Addressbook</b></td>
<td valign="top" align="left">apps/addressbook</td>
<td valign="top" align="left">addressbook.war</td>
<td valign="top" align="left">
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a></td>
<td valign="top" align="left">Ragnarok</td>
</tr>
<tr>
<td valign="top" align="left"><b>I2PSnark</b></td>
<td valign="top" align="left">apps/i2psnark</td>
<td valign="top" align="left">i2psnark.jar</td>
<td valign="top" align="left">
<a href="#java_exception">GPL + exception</a></td>
<td valign="top" align="left">&nbsp;</td>
<td valign="top" align="left">zzz</td>
</tr>
<tr>
<td valign="top" align="left"><b>Susidns</b></td>
<td valign="top" align="left">apps/susidns</td>
<td valign="top" align="left">susidns.war</td>
<td valign="top" align="left">
<a href="#java_exception">GPL + exception</a></td>
<td valign="top" align="left">&nbsp;</td>
<td valign="top" align="left">&nbsp;</td>
</tr>
<tr>
<td valign="top" align="left"><b>Susimail</b></td>
<td valign="top" align="left">apps/susimail</td>
<td valign="top" align="left">susimail.war</td>
<td valign="top" align="left">
<a href="#java_exception">GPL + exception</a></td>
<td valign="top" align="left">&nbsp;</td>
<td valign="top" align="left">&nbsp;</td>
</tr>
<tr>
<td valign="top" align="left"><b>Other apps not mentioned</b></td>
<td valign="top" align="left">apps/</td>
<td valign="top" align="left">...</td>
<td valign="top" align="left">
probably
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a>
but check the source</td>
<td valign="top" align="left">&nbsp;</td>
<td valign="top" align="left">&nbsp;</td>
</tr>
<tr>
<td valign="top" align="left"><b>Installer</b></td>
<td valign="top" align="left">installer</td>
<td valign="top" align="left">install.jar, guiinstall.jar</td>
<td valign="top" align="left">
<a href="http://en.wikipedia.org/wiki/Public_domain">Public domain</a></td>
<td valign="top" align="left"><a href="#java_exception">GPL + exception</a><br />
<a href="http://opensource.org/licenses/bsd-license.php">BSD</a><br />
<a href="http://www.cryptix.org/LICENSE.TXT">Cryptix</a><br />
<a href="http://opensource.org/licenses/mit-license.html">MIT</a></td>
<td valign="top" align="left">&nbsp;</td>
</tr>
</table>
<h3><a id="java_exception">GPL + java exception</a></h3>
<p>While it may be redundant, just for clarity the
<a href="http://www.fsf.org/licenses/gpl.html">GPL</a>'ed code included within
I2PTunnel and other apps must be released under the GPL with an additional "exception"
explicitly authorizing the use of Java's standard libraries:</p>
<p><code>In addition, as a special exception, XXXX gives permission to link the
code of this program with the proprietary Java implementation provided by Sun
(or other vendors as well), and distribute linked combinations including the
two. You must obey the GNU General Public License in all respects for all of the
code used other than the proprietary Java implementation. If you modify this
file, you may extend this exception to your version of the file, but you are not
obligated to do so. If you do not wish to do so, delete this exception statement
from your version.</code></p>
<p>All source code under each component will by default be licensed under the
primary license, unless marked otherwise in the code. All of the above is
summary of the license terms - please see the specific license for the component
or source code in question for authoritative terms. Component source locations and
resource packaging may be changed if the repository is reorganized.</p>
<h2><a id="commit">Commit privileges</a></h2>
<p>
Developers may push changes to a distributed monotone repository if you
receive permission from the person running that repository.
See the <a href="monotone.html">Monotone Page</a> for details.
</p>
<p>
However, to have changes included in a release, developers
must be trusted by the release manager (currently zzz).
In addition, they must explicitly agree with the above terms to be trusted.
That means that they must send one of the release managers a signed message affirming that:</p>
<ul>
<li>Unless marked otherwise, all code I commit is implicitly licensed under
the component's primary license</li>
<li>If specified in the source, the code may be explicitly licensed under one
of the component's alternate licenses</li>
<li>I have the right to release the code I commit under the terms I
am committing it</li>
</ul>
<p>If anyone is aware of any instances where the above conditions are not met,
please contact the component lead and/or an I2P release manager with further
information.
<a href="{{ site_url('develop/license-agreements') }}">See developers' license agreements</a>.
</p>
{% endblock %}

1037
i2p2www/pages/site/develop/monotone.html Normal file
View File

File diff suppressed because it is too large Load Diff

418
i2p2www/pages/site/docs/how/cryptography.html Normal file
View File

@@ -0,0 +1,418 @@
{% extends "global/layout.html" %}
{% block title %}Low-level Cryptography Details{% endblock %}
{% block content %}
<p>
Updated March 2012, current as of router version 0.8.13
<p>
This page specifies the low-level details of the cryptography in I2P.
<p>
There are a handful of cryptographic algorithms in use within I2P, but we have
reduced them to a bare minimum to deal with our needs - one symmetric algorithm
one asymmetric algorithm, one signing algorithm, and one hashing algorithm. However,
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="{{ 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>
<p>
ElGamal is used for asymmetric encryption.
ElGamal is used in several places in I2P:
<ul><li>
To encrypt router-to-router <a href="tunnel-alt-creation.html">Tunnel Build Messages</a>
</li><li>
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="{{ 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>
</p>
<p>
We use common primes for 2048 ElGamal encryption and decryption, as given by <a href="http://tools.ietf.org/html/rfc3526">IETF RFC-3526</a>.
We currently only use ElGamal to encrypt the IV and session key in a single block, followed by the
AES encrypted payload using that key and IV.
<p>
The unencrypted ElGamal contains:
</p>
<p>
<PRE>
+----+----+----+----+----+----+----+----+
|nonz| H(data) |
+----+ +
| |
+ +
| |
+ +
| |
+ +----+----+----+----+----+----+----+
| | data...
+----+----+----+--//
</PRE>
<p>
The H(data) is the SHA256 of the data that is encrypted in the ElGamal block,
and is preceded by a nonzero byte.
This byte could be random, but as implemented it is always 0xFF.
It could possibly be used for flags in the future.
The data encrypted in the block may be up to 222 bytes long.
As the encrypted data may contain a substantial number of zeros if the
cleartext is smaller than 222 bytes, it is recommended that higher layers pad
the cleartext to 222 bytes with random data.
Total length: typically 255 bytes.
</p><p>
The encrypted ElGamal contains:
</p>
<p>
<PRE>
+----+----+----+----+----+----+----+----+
| zero padding... | |
+----+----+----+--// ----+ +
| |
+ +
| ElG encrypted part 1 |
~ ~
| |
+ +----+----+----+----+----+----+----+
| | zero padding... | |
+----+----+----+----+--// ----+ +
| |
+ +
| ElG encrypted part 2 |
~ ~
| |
+ +----+----+----+----+----+----+
| +
+----+----+
</PRE>
Each encrypted part is prepended with zeros to a size of exactly 257 bytes.
Total length: 514 bytes.
In typical usage, higher layers pad the cleartext data to 222 bytes,
resulting in an unencrypted block of 255 bytes.
This is encoded as two 256-byte encrypted parts,
and there is a single byte of zero padding before each part at this layer.
</p><p>
See
<a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/ElGamalEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">the ElGamal code</a>.
<p>
The shared prime is the
<a href="http://tools.ietf.org/html/rfc3526#section-3">[Oakley prime for 2048 bit keys]</a>
<PRE>
2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
</PRE>
or as a hexadecimal value:
<PRE>
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
</PRE>
<p>
Using 2 as the generator.
<h3>Short Exponent</h3>
While the standard exponent size is 2048 bits (256 bytes) and the I2P
<a href="common_structures_spec.html#type_PrivateKey">PrivateKey</a>
is a full 256 bytes,
we use the short exponent size of 226 bits (28.25 bytes).
This should be safe for use with the Oakley primes,
per
<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.5952&amp;rep=rep1&amp;type=pdf">
On Diffie-Hellman Key Agreement with Short Exponents - van Oorschot, Weiner</a>
at EuroCrypt 96, and
<a href="benchmarks.html">crypto++'s benchmarks</a>.
Benchmarks originally at <a rel="nofollow" href="http://www.eskimo.com/~weidai/benchmarks.html">this link, now dead</a>,
rescued from <a href="http://www.archive.org/">the wayback machine</a>, dated Apr 23, 2008.
<p>
Also,
<a href="http://www.springerlink.com/content/2jry7cftp5bpdghm/">
Koshiba &amp; Kurosawa: Short Exponent Diffie-Hellman Problems</a> (PKC 2004, LNCS 2947, pp. 173-186)
<a href="http://books.google.com/books?id=cXyiNZ2_Pa0C&amp;lpg=PA173&amp;ots=PNIz3dWe4g&amp;pg=PA173#v=onepage&amp;q&amp;f=false">
(full text on google books)</a>
apparently supports this, according to
<a href="http://groups.google.com/group/sci.crypt/browse_thread/thread/1855a5efa7416677/339fa2f945cc9ba0#339fa2f945cc9ba0">this sci.crypt thread</a>.
The remainder of the PrivateKey is padded with zeroes.
<H4>Obsolescence</H4>
<p>
The vulnerability of the network to an ElGamal attack and the impact of transitioning to a longer bit length is to be studied.
It may be quite difficult to make any change backward-compatible.
</p>
<H2><a name="AES">AES</a></H2>
<p>
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="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
</li><li>
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="{{ 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.
The padding used is specified in <a href="http://tools.ietf.org/html/rfc2313">IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02))</a>.
In this case, padding exists of pseudorandomly generated octets to match 16 byte blocks.
Specifically, see
<a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/CryptixAESEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">[the CBC code]</a>
and the Cryptix AES
<a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/CryptixRijndael_Algorithm.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">[implementation]</a>,
as well as the padding, found in the
<a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/ElGamalAESEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">ElGamalAESEngine.getPadding</a> function.
<!-- *********************************************************************************
Believe it or not, we don't do this any more. If we ever did. safeEncode() and safeDecode() are unused.
<p>
In all cases, we know the size of the data to be sent, and we AES encrypt the following:
<p>
<PRE>
+----+----+----+----+----+----+----+----+
| H(data) |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| size | data ... |
+----+----+----+----+ +
| |
~ ~
| |
+ +
| |
+ +----//---+----+
| | |
+----+----+----//---+----+ +
| Padding to 16 bytes |
+----+----+----+----+----+----+----+----+
H(data): 32-byte SHA-256 Hash of the data
size: 4-byte Integer, number of data bytes to follow
data: payload
padding: random data, to a multiple of 16 bytes
</PRE>
<p>
After the data comes an application-specified number of randomly generated padding bytes.
This application-specified number is rounded up to a multiple of 16.
The entire segment (from H(data) through the end of the random bytes) is AES encrypted
(256 bit CBC w/ PKCS#5).
<p>
This code is implemented in the safeEncrypt and safeDecrypt methods of
AESEngine but it is unused.
</p>
*************************************************************** -->
<H4>Obsolescence</H4>
<p>
The vulnerability of the network to an AES attack and the impact of transitioning to a longer bit length is to be studied.
It may be quite difficult to make any change backward-compatible.
</p>
<H4>References</H4>
<ul>
<li>
<a href="status-2006-02-07.html">Feb. 7, 2006 Status Notes</a>
</ul>
<H2><a name="DSA">DSA</a></H2>
<p>
Signatures are generated and verified with 1024 bit DSA (L=1024, N=160), as implemented in
<a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/DSAEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">[DSAEngine]</a>.
DSA was chosen because it is much faster for signatures than ElGamal.
<p>
<H3>The DSA constants</H3>
<p>
<H4>SEED</H4>
<p>160 bit</p>
<PRE>
86108236b8526e296e923a4015b4282845b572cc
</PRE>
<H4>Counter</H4>
<PRE>
33
</PRE>
<p>
<H4>DSA prime (p)</H4>
<p>1024 bit</p>
<p>
<PRE>
9C05B2AA 960D9B97 B8931963 C9CC9E8C 3026E9B8 ED92FAD0
A69CC886 D5BF8015 FCADAE31 A0AD18FA B3F01B00 A358DE23
7655C496 4AFAA2B3 37E96AD3 16B9FB1C C564B5AE C5B69A9F
F6C3E454 8707FEF8 503D91DD 8602E867 E6D35D22 35C1869C
E2479C3B 9D5401DE 04E0727F B33D6511 285D4CF2 9538D9E3
B6051F5B 22CC1C93
</PRE>
<p>
<H4>DSA quotient (q)</H4>
<p>
<PRE>
A5DFC28F EF4CA1E2 86744CD8 EED9D29D 684046B7
</PRE>
<p>
<H4>DSA generator (g)</H4>
<p>1024 bit</p>
<p>
<PRE>
C1F4D27D 40093B42 9E962D72 23824E0B BC47E7C8 32A39236
FC683AF8 48895810 75FF9082 ED32353D 4374D730 1CDA1D23
C431F469 8599DDA0 2451824F F3697525 93647CC3 DDC197DE
985E43D1 36CDCFC6 BD5409CD 2F450821 142A5E6F 8EB1C3AB
5D0484B8 129FCF17 BCE4F7F3 3321C3CB 3DBB14A9 05E7B2B3
E93BE470 8CBCC82
</PRE>
<p>
The <a href="common_structures_spec.html#type_SigningPublicKey">Signing Public Key</a> is 1024 bits.
The <a href="common_structures_spec.html#type_SigningPrivateKey">Signing Private Key</a> is 160 bits.
</p>
<H4>Obsolescence</H4>
<p>
<a href="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf">NIST 800-57</a>
recommends a minimum of (L=2048, N=224) for usage beyond 2010.
This may be mitigated somewhat by the "cryptoperiod", or lifespan of a given key.
</p>
<p>
The prime number was chosen <a href="#choosing_constants">in 2003</a>,
and the person that chose the number (TheCrypto) is currently no longer an I2P developer.
As such, we do not know if the prime chosen is a 'strong prime'.
If a larger prime is chosen for future purposes, this should be a strong prime, and we will document the construction process.
</p>
<p>
The vulnerability of the network to a DSA attack and the impact of transitioning to longer keys is to be studied.
It may be quite difficult to make any change backward-compatible.
</p>
<H4>References</H4>
<ul>
<li>
<a href="{{ url_for('meetings_show', lang=g.lang, id=51) }}">Meeting 51</a>
<li>
<a href="{{ url_for('meetings_show', lang=g.lang, id=52) }}">Meeting 52</a>
<li>
<a name="choosing_constants" href="http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/343">Choosing the constants</a>
<li>
<a href="http://en.wikipedia.org/wiki/Digital_Signature_Algorithm">DSA</a>
</ul>
<H2><a name="SHA256">SHA256</a></H2>
<p>
Hashes within I2P are plain old SHA256, as implemented in
<a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/SHA256Generator.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">[SHA256Generator]</a>
<H4>Obsolescence</H4>
<p>
The vulnerability of the network to a SHA-256 attack and the impact of transitioning to a longer hash is to be studied.
It may be quite difficult to make any change backward-compatible.
</p>
<H4>References</H4>
<ul>
<li>
<a href="http://en.wikipedia.org/wiki/SHA-2">SHA-2</a>
</ul>
<h2 id="transports">Transports</h2>
<p>
At the lowest protocol layer,
point-to-point inter-router communication is protected by the transport layer security.
Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange
using
<a href="#elgamal">the same shared prime and generator as specified above for ElGamal</a>,
followed by symmetric AES encryption as described above.
This provides
<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">perfect forward secrecy</a>
on the transport links.
</p>
<H3><a name="tcp">NTCP connections</a></H3>
<p>
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="{{ 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:
<p>
<OL>
<li> can we somehow reestablish sessions securely (ala session tags) or do we need to do full negotiation each time?
<li> can we simplify/avoid the x509 or other certificate formats and use our own RouterInfo structure (which
contains the ElGamal and DSA keys)?
</OL>
<p>
See <a href="ntcp.html">the NTCP specification</a> for details.
<H3><a name="udp">UDP connections</a></H3>
SSU (the UDP transport) encrypts each packet with AES256/CBC with both an explicit IV and MAC
(HMAC-MD5-128) after agreeing upon an ephemeral session key through a 2048 bit
Diffie-Hellman exchange, station-to-station authentication with the other
router's DSA key, plus each network message has their own hash for local integrity
checking.
<p>
See <a href="udp.html#keys">the SSU specification</a> for details.
<p>
WARNING - I2P's HMAC-MD5-128 used in SSU is apparently non-standard.
Apparently, an early version of SSU used HMAC-SHA256, and then it was switched
to MD5-128 for performance reasons, but left the 32-byte buffer size intact.
See HMACGenerator.java and
<a href="status-2005-07-05.html">the 2005-07-05 status notes</a>
for details.
<H2>References</H2>
<ul>
<li>
<a href="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf">NIST 800-57</a>
</ul>
{% endblock %}

329
i2p2www/pages/site/docs/how/elgamalaes.html Normal file
View File

@@ -0,0 +1,329 @@
{% extends "global/layout.html" %}
{% block title %}ElGamal/AES + SessionTag Encryption{% endblock %}
{% block content %}
Updated February 2011, current as of router version 0.8.3
<h2>Overview</h2>
<p>
ElGamal/AES+SessionTags is used for end-to-end encryption.
</p>
<p> As an unreliable, unordered, message based system, I2P uses a simple combination
of asymmetric and symmetric encryption algorithms to provide data confidentiality
and integrity to garlic messages. As a whole, the combination is referred
to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe
the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces. </p>
<p> The first time a router wants to encrypt a garlic message to another router,
they encrypt the keying material for an AES256 session key with ElGamal and
append the AES256/CBC encrypted payload after that encrypted ElGamal block.
In addition to the encrypted payload, the AES encrypted section contains the
payload length, the SHA256 hash of the unencrypted payload, as well as a number
of "session tags" - random 32 byte nonces. The next time the sender wants
to encrypt a garlic message to another router, rather than ElGamal encrypt
a new session key they simply pick one of the previously delivered session
tags and AES encrypt the payload like before, using the session key used with
that session tag, prepended with the session tag itself. When a router receives
a garlic encrypted message, they check the first 32 bytes to see if it matches
an available session tag - if it does, they simply AES decrypt the message,
but if it does not, they ElGamal decrypt the first block. </p>
<p> Each session tag can be used only once so as to prevent internal adversaries
from unnecessarily correlating different messages as being between the same
routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses
when and how many tags to deliver, prestocking the recipient with enough tags
to cover a volley of messages. Garlic messages may detect the successful tag
delivery by bundling a small additional message as a clove (a "delivery status
message") - when the garlic message arrives at the intended recipient and
is decrypted successfully, this small delivery status message is one of the
cloves exposed and has instructions for the recipient to send the clove back
to the original sender (through an inbound tunnel, of course). When the original
sender receives this delivery status message, they know that the session tags
bundled in the garlic message were successfully delivered. </p>
<p> Session tags themselves have a short lifetime, after which they are
discarded if not used. In addition, the quantity stored for each key is limited,
as are the number of keys themselves - if too many arrive, either new or old
messages may be dropped. The sender keeps track whether messages using session
tags are getting through, and if there isn't sufficient communication it may
drop the ones previously assumed to be properly delivered, reverting back
to the full expensive ElGamal encryption.
A session will continue to exist until all its tags are exhausted or expire.
</p><p>
Sessions are unidirectional. Tags are delivered from Alice to Bob,
and Alice then uses the tags, one by one, in subsequent messages to Bob.
</p><p>
Sessions may be established between Destinations, between Routers, or
between a Router and a Destination.
Each Router and Destination maintains its own Session Key Manager to
keep track of Session Keys and Session Tags.
Separate Session Key Managers prevents correlation of multiple Destinations
to each other or a Router by adversaries.
</p>
<h2>Message Reception</h2>
<p>
Each message received has one of two
the two possible conditions:</p>
<OL>
<li> It is part of an existing session and contains a Session Tag and an AES encrypted block</li>
<li> It is for a new session and contains both ElGamal and AES encrypted blocks</li>
</OL>
When a router receives a message, it will first assume it is from
an existing session and attempt to look up the Session Tag and decrypt the following data using AES.
If that fails, it will assume it is for a new session and attempt to
decrypt it using ElGamal.
</p>
<h2 id="new">New Session Message Specification</h2>
<p>
A New Session ElGamal Message contains two parts, an encrypted ElGamal block
and an encrypted AES block.
</p><p>
The encrypted message contains:
<PRE>
+----+----+----+----+----+----+----+----+
| |
+ +
| ElGamal Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| | |
+----+----+ +
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| +
+----+----+
</PRE>
</p>
<h3>ElGamal Block</h3>
<p>
The encrypted ElGamal Block is always 514 bytes long.
</p><p>
The unencrypted ElGamal data is 222 bytes long, containing:
<PRE>
+----+----+----+----+----+----+----+----+
| |
+ +
| Session Key |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| Pre-IV |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
+ +
| |
+ +
| 158 bytes random padding |
~ ~
| |
+ +----+----+
| |
+----+----+----+----+----+----+
</PRE>
The 32-byte
<a href="common_structures_spec#type_SessionKey">Session Key</a>
is the identifier for the session.
The 32-byte Pre-IV will be used to generate the IV for the AES block that follows;
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="{{ site_url('docs/how/cryptography') }}#elgamal">using ElGamal</a>
and the encrypted block is 514 bytes long.
</p>
<h3 id="aes">AES Block</h3>
<p>The unencrypted data in the AES block contains the following:
<PRE>
+----+----+----+----+----+----+----+----+
|tag count| |
+----+----+ +
| |
+ +
| Session Tags |
~ ~
| |
+ +
| |
+ +----+----+----+----+----+----+
| | payload size | |
+----+----+----+----+----+----+ +
| |
+ +
| Payload Hash |
+ +
| |
+ +----+----+
| |flag| |
+----+----+----+----+----+----+----+ +
| |
+ +
| New Session Key (opt.) |
+ +
| |
+ +----+
| | |
+----+----+----+----+----+----+----+ +
| |
+ +
| Payload |
~ ~
| |
+ +----//---+----+
| | |
+----+----+----//---+----+ +
| Padding to 16 bytes |
+----+----+----+----+----+----+----+----+
tag count: 2-byte <a href="common_structures_spec#type_Integer">Integer</a>, 0-200
Session Tags: That many 32-byte <a href="common_structures_spec#type_SessionTag">Session Tags</a>
payload size: 4-byte <a href="common_structures_spec#type_Integer">Integer</a>
Payload Hash: The 32-byte <a href="common_structures_spec#type_Hash">SHA256 Hash</a> of the payload
flag: A one-byte value. Normally == 0. If == 0x01, a Session Key follows
New Session Key: A 32-byte <a href="common_structures_spec#type_SessionKey">Session Key</a>,
to replace the old key, and is only present if preceding flag is 0x01
Payload: the data
Padding: Random data to a multiple of 16 bytes for the total length.
May contain more than the minimum required padding.
Minimum length: 48 bytes
</PRE>
</p><p>
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>
<h4>Notes</h4>
<ul>
<li>
Actual max payload length, and max block length, is less than 64 KB; see the <a href="i2np.html">I2NP Overview</a>.
</li><li>
New Session Key is currently unused and is never present.
</li></ul>
<h2 id="existing">Existing Session Message Specification</h2>
<p>The session tags delivered successfully are remembered for a
brief period (15 minutes currently) until they are used or discarded.
A tag is used by packaging one in an Existing Session Message that
contains only an AES encrypted block, and
is not preceded by an
ElGamal block.
</p><p?>
The existing session message is
as follows:
<PRE>
+----+----+----+----+----+----+----+----+
| |
+ +
| Session Tag |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
Session Tag: A 32-byte <a href="common_structures_spec#type_SessionTag">Session Tag</a>
previously delivered in an AES block
AES Encrypyted Block: As specified <a href="#aes">above</a>.
</PRE>
The session tag also serves as
the pre-IV. The IV is the first 16 bytes of the SHA-256 Hash of the sessionTag.
</p><p>
To decode a message from an existing session, a router looks up the Session Tag to find an
associated Session Key. If the Session Tag is found, the AES block is decrypted using the associated Session Key.
If the tag is not found, the message is assumed to be a <a href="#new">New Session Message</a>.
</p>
<h2 id="future">Future Work</h2>
<p>
There are many possible areas to tune the Session Key Manager's algorithms;
some may interact with the streaming library behavior, or have significant
impact on overall performance.
<ul><li>
Delivery of too many tags at one time may impose substantial overhead for brief streaming connections
or datagrams, and increase the chance of message loss.
We currently deliver 40 tags at a time (1280 bytes).
32 (1024 bytes) may be better for tunnel fragmentation.
</li><li>
A few tags could be delivered in each of several messages, or lots of tags all at once.
</li><li>
It is also important to study and tune
the low-tag thresholds at which more tags are sent.
</li><li>
The number of tags delivered could depend on message size, keeping in mind
the eventual padding to 1KB at the tunnel message layer.
</li><li>
Clients could send an estimate of session lifetime to the router, as an advisory
on the number of tags required.
</li><li>
Delivery of too few tags causes the router to fall back to an expensive ElGamal encryption.
</li><li>
The router may assume delivery of Session Tags, or await acknowledgement before using them;
there are tradeoffs for each strategy.
</li><li>
For very brief messages, almost the full 222 bytes of the pre-IV and padding fields in the ElGamal block
could be used for the entire message, instead of establishing a session.
</li><li>
Evaluate padding strategy; currently we pad to a minimum of 128 bytes.
Would be better to add a few tags to small messages than pad.
</li><li>
Perhaps things could be more efficient if the Session Tag system was bidirectional,
so tags delivered in the 'forward' path could be used in the 'reverse' path,
thus avoiding ElGamal in the initial response.
The router currently plays some tricks like this when sending
tunnel test messages to itself.
</li><li>
Change from Session Tags to
<a href="performance.html#prng">a synchronized PRNG</a>.
</li><li>
Several of these ideas may require a new I2NP message type, or
set a flag in the
<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>,
or set a magic number in the first few bytes of the Session Key field
and accept a small risk of the random Session Key matching the magic number.
</li></ul>
</p>
{% endblock %}

259
i2p2www/pages/site/docs/how/garlicrouting.html Normal file
View File

@@ -0,0 +1,259 @@
{% extends "global/layout.html" %}
{% block title %}Garlic Routing{% endblock %}
{% block content %}<p>
Updated August 2010 for release 0.8
</p>
<h2>Garlic Routing and "Garlic" Terminology</h2>
<p>
The terms "garlic routing" and "garlic encryption" are often used rather loosely when referring to I2P's technology.
Here, we explain the history of the terms, the various meanings, and
the usage of "garlic" methods in I2P.
</p><p>
"Garlic routing" was first coined by
<a href="http://www.cs.princeton.edu/~mfreed/">Michael J. Freedman</a>
in Roger Dingledine's Free Haven
<a href="http://www.freehaven.net/papers.html">Master's thesis</a> Section 8.1.1 (June 2000), as derived from
<a href="http://onion-router.net/">Onion Routing</a>.
</p><p>
"Garlic" may have been used originally by I2P developers because I2P implements a form of
bundling as Freedman describes, or simply to emphasize general differences from Tor.
The specific reasoning may be lost to history.
Generally, when referring to I2P, the term "garlic" may mean one of three things:
<ol><li>
Layered Encryption
</li><li>
Bundling multiple messages together
</li><li>
ElGamal/AES Encryption
</li></ol>
Unfortunately, I2P's usage of "garlic" terminology over the past seven years has not always been precise; therefore the reader is
cautioned when encountering the term.
Hopefully, the explanation below will make things clear.
</p>
<h3>Layered Encryption</h3>
<p>
Onion routing is a technique for building paths, or tunnels, through a series of peers,
and then using that tunnel.
Messages are repeatedly encrypted by the originator, and then decrypted by each hop.
During the building phase, only the routing instructions for the next hop are exposed to each peer.
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="{{ 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
per hop along the path.
</p><p>
In this sense, "garlic routing" as a general concept is identical to "onion routing".
As implemented in I2P, of course, there are several differences from the implementation in Tor; see below.
Even so, there are substantial similarities such that I2P benefits from a
<a href="http://www.onion-router.net/Publications.html">large amount of academic research on onion routing</a>,
<a href="http://freehaven.net/anonbib/topic.html">Tor, and similar mixnets</a>.
</p>
<h3>Bundling Multiple Messages</h3>
<p>
Michael Freedman defined "garlic routing" as an extension to onion routing,
in which multiple messages are bundled together.
He called each message a "bulb".
All the messages, each with its own delivery instructions, are exposed at the
endpoint.
This allows the efficient bundling of an onion routing "reply block" with the original message.
</p><p>
This concept is implemented in I2P, as described below.
Our term for garlic "bulbs" is "cloves".
Any number of messages can be
contained, instead of just a single message.
This is a significant distinction from the onion routing implemented in Tor.
However, it is only one of many major architectural differences between I2P and Tor;
perhaps it is not, by itself, enough to justify a change in terminology.
</p><p>
Another difference
from the method described by Freedman
is that the path is unidirectional - there is no "turning point" as seen in onion routing
or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible
and reliable delivery.
</p>
<h3>ElGamal/AES Encryption</h3>
In some cases, "garlic encryption" may simply mean
<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption
(without multiple layers).
<H2>"Garlic" Methods in I2P</H2>
<p>
Now that we've defined various "garlic" terms, we can say that
I2P uses garlic routing, bundling and encryption in three places:
<ol>
<li> For building and routing through tunnels (layered encryption)
<li> For determining the success or failure of end to end message delivery (bundling)
<li> For publishing some network database entries (dampening the probability of a successful traffic analysis attack)
(ElGamal/AES)
</ol>
<p>
There are also significant ways that this technique can be used to improve the performance of the network,
exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability.
<h3>Tunnel Building and Routing</h3>
<p>
In I2P, tunnels are unidirectional. Each party builds two tunnels,
one for outbound and one for inbound traffic.
Therefore, four tunnels are required for a single round-trip message and reply.
</p><p>
Tunnels are built, and then used, with layered encryption.
This is described on the
<a href="tunnel-alt.html">tunnel implementation page</a>.
Tunnel building details are defined on
<a href="tunnel-alt-creation.html">this page</a>.
We use
<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
<a href="i2np_spec.html#msg_Garlic">Garlic Messages</a> are not used to build tunnels.
We do not bundle multiple
<a href="i2np.html">I2NP messages</a> into a single
<a href="i2np_spec.html#msg_Garlic">Garlic Message</a> for unwrapping at the outbound tunnel endpoint;
the tunnel encryption is sufficient.
</p>
<h3>End-to-End Message Bundling</h3>
<p>
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="{{ 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>
with its own
<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>,
inside a
<a href="i2np.html#msg_Garlic">Garlic Message</a>.
Delivery Instructions may specify a Destination, Router, or Tunnel.
</p><p>
Generally, a Garlic Message will contain only one clove.
However, the router will periodically bundle two additional
cloves in the Garlic Message:
<img src="/_static/images/garliccloves.png" alt="Garlic Message Cloves" style="text-align:center;"/>
<ol><li>
A
<a href="i2np.html#msg_DeliveryStatus">Delivery Status Message</a>,
with
<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>
specifying that it be sent back to the originating router as an acknowledgment.
This is similar to the "reply block" or "reply onion"
described in the references.
It is used for determining the success or failure of end to end message delivery.
The originating router may, upon failure to receive the Delivery Status Message
within the expected time period, modify the routing to the far-end Destination,
or take other actions.
</li><li>
A
<a href="i2np.html#msg_DatabaseStore">Database Store Message</a>,
containing a
<a href="common_structures_spec#struct_LeaseSet">LeaseSet</a>
for the originating Destination, with
<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>
specifying the far-end destination's router.
By periodically bundling a LeaseSet, the router ensures that the far-end will be able
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="{{ site_url('docs/how/networkdatabase') }}">network database page</a>.
</li></ol>
</p><p>
In the current implementation, the Delivery Status and Database Store Messages
are bundled when the local LeaseSet changes, when additional
<a href="common_structures_spec#type_SessionTag">Session Tags</a>
are delivered, or if the messages have not been bundled in the previous minute.
</p><p>
Obviously, the additional messages are currently bundled for specific purposes,
and not part of a general-purpose routing scheme.
</p>
<h3> Storage to the Floodfill Network Database</h3>
</p>
As explained on the
<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
<a href="i2np.html#msg_DatabaseStore">Database Store Message</a>
wrapped in a
<a href="i2np.html#msg_Garlic">Garlic Message</a>
so it is not visible to the tunnel's outbound gateway.
</p>
<H2>Future Work</H2>
<p>
The Garlic Message mechanism is very flexible and provides a structure for
implementing many types of mixnet delivery methods.
Together with the unused delay option in the
<a href="tunnel_message_spec.html#delivery">tunnel message Delivery Instructions</a>,
a wide spectrum of batching, delay, mixing, and routing strategies are possible.
</p><p>
In particular, there is potential for much more flexibility at the outbound tunnel endpoint.
Messages could possibly be routed from there to one of several tunnels
(thus minimizing point-to-point connections), or multicast to several tunnels
for redundancy, or streaming audio and video.
</p><p>
Such experiments may conflict with the need to ensure security and anonymity, such
as limiting certain routing paths, restricting the types of I2NP messages that may
be forwarded along various paths, and enforcing certain message expiration times.
</p><p>
As a part of
<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="{{ site_url('docs/how/networkdatabase') }}#delivery">floodfill routers</a>.
</p>
<H2>References</H2>
<ul><li>
The term garlic routing was first coined in Roger Dingledine's Free Haven
<a href="http://www.freehaven.net/papers.html">Master's thesis</a> (June 2000),
see Section 8.1.1 authored by
<a href="http://www.cs.princeton.edu/~mfreed/">Michael J. Freedman</a>.
</li><li>
<a href="http://www.onion-router.net/Publications.html">Onion router publications</a>
</li><li>
<a href="http://en.wikipedia.org/wiki/Onion_routing">Onion Routing on Wikipedia</a>
</li><li>
<a href="http://en.wikipedia.org/wiki/Garlic_routing">Garlic Routing on Wikipedia</a>
</li><li>
<a href="{{ url_for('meetings_show', lang=g.lang, id=58) }}">I2P Meeting 58</a> (2003) discussing the implementation of garlic routing
</li><li>
<a href="https://www.torproject.org/">Tor</a>
</li><li>
<a href="http://freehaven.net/anonbib/topic.html">Free Haven publications</a>
</li><li>
Onion routing was first described in <a href="http://www.onion-router.net/Publications/IH-1996.pdf">Hiding Routing Information</a>
by David M. Goldschlag, Michael G. Reed, and Paul F. Syverson in 1996.
</li></ul>
{% endblock %}

227
i2p2www/pages/site/docs/how/index.html Normal file
View File

@@ -0,0 +1,227 @@
{% extends "global/layout.html" %}
{% block title %}Index to Technical Documentation{% endblock %}
{% block content %}
<h1>How does I2P work?</h1>
<p>
Following is an index to the technical documentation for I2P.
This page was last updated in May 2012 and is accurate for router version 0.9.
</p><p>
This index is ordered from the highest to lowest layers.
The higher layers are for "clients" or applications;
the lower layers are inside the router itself.
The interface between applications and the router is the I2CP (I2P Control Protocol) API.
</p><p>
The I2P Project is committed to maintaining accurate, current documentation.
If you find any inaccuracies in the documents linked below, please
<a href="http://trac.i2p2.de/report/1">enter a ticket identifying the problem</a>.
</p>
<h2>Index to Technical Documentation</h2>
<h3>Overview</h3>
<ul class="helplist">
<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>
</ul>
<h3>Application-Layer Topics</h3>
<ul>
<li><a href="naming.html">Naming and Addressbook</a></li>
<li><a href="plugins.html">Plugins Overview</a></li>
<li><a href="plugin_spec.html">Plugin Specification</a></li>
<li><a href="updates.html">Router software updates</a></li>
<li><a href="bittorrent.html">Bittorrent over I2P</a></li>
<li><a href="i2pcontrol.html">I2PControl Plugin API</a></li>
<li><a href="blockfile.html">hostsdb.blockfile Format</a></li>
</ul>
<h3>Application Layer API and Protocols</h3>
High-level, easy-to-use APIs for applications written in any language to send and receive data.
<ul><li>
<a href="applications.html">Application Development Overview and Guide</a>
</li><li>
<a href="i2ptunnel.html">I2PTunnel</a>
</li><li>
<a href="socks.html">SOCKS Proxy</a>
</li><li>
HTTP Proxy
</li><li>
CONNECT Proxy
</li><li>
IRC Proxy
</li><li>
SOCKS IRC Proxy
</li><li>
Streamr Proxy
</li><li>
HTTP Bidir Proxy
</li><li>
<a href="sam.html">SAM Protocol</a>
</li><li>
<a href="samv2.html">SAMv2 Protocol</a>
</li><li>
<a href="samv3.html">SAMv3 Protocol</a>
</li><li>
<a href="bob.html">BOB Protocol</a>
</li></ul>
<h3>End-to-End Transport API and Protocols</h3>
The end-to-end protocols used by clients for reliable and unreliable communication.
<ul><li>
<a href="streaming.html">Streaming Library</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/package-summary.html">Streaming Javadoc</a>
</li><li>
<a href="datagrams.html">Datagrams</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/client/datagram/package-summary.html">Datagram Javadoc</a>
</li></ul>
<h3>Client-to-Router Interface API and Protocol</h3>
The lowest-level API used for clients (applications) to send and receive traffic to a router.
Traditionally used only by Java applications and higher-level APIs.
<ul><li>
<a href="i2cp.html">I2CP</a> I2P Control Protocol / API overview
</li><li>
<a href="i2cp_spec.html">I2CP Specification</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html">I2CP API Javadoc</a>
</li><li>
<a href="common_structures_spec.html">Common data structures specification</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/package-summary.html">Data Structures Javadoc</a>
</li></ul>
<h3>End-to-End Encryption</h3>
How client messages are end-to-end encrypted by the router.
<ul>
<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="{{ 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>
I2P is a message-oriented router. The messages sent between routers are defined by the I2NP protocol.
<ul><li>
<a href="i2np.html">I2NP</a> I2P Network Protocol Overview
</li><li>
<a href="i2np_spec.html">I2NP Specification</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/i2np/package-summary.html">I2NP Javadoc</a>
</li><li>
<a href="common_structures_spec.html">Common data structures specification</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/package-summary.html">Data Structures Javadoc</a>
</li></ul>
<h3>Tunnels</h3>
Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.
<ul>
<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="{{ 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>
<li><a href="{{ url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') }}">Peer Profiling and Selection in the I2P Anonymous Network</a>
2009 paper (pdf), not current but still generally accurate</li>
</ul>
<h3>Transport Layer</h3>
The protocols for direct (point-to-point) router to router communication.
<ul><li>
<a href="transport.html">Transport layer overview</a>
</li><li>
<a href="ntcp.html">NTCP</a> TCP-based transport overview and specification
</li><li>
<a href="udp.html">SSU</a> UDP-based transport overview
</li><li>
<a href="udp_spec.html">SSU specification</a>
</li><li>
<a href="{{ site_url('docs/how/cryptography') }}#tcp">NTCP transport encryption</a>
</li><li>
<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>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/transport/ntcp/package-summary.html">NTCP Javadoc</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/transport/udp/package-summary.html">SSU Javadoc</a>
</li></ul>
<h3>Other Router Topics</h3>
<ul><li>
<a href="jbigi.html">Native BigInteger Library</a>
</li><li>
Time synchronization and NTP
</li><li>
<a href="performance.html">Performance</a> (not current)
</li></ul>
<h3>Developer's Guides and Resources</h3>
<ul><li>
<a href="newdevelopers.html">New Developer's Guide</a>
</li><li>
<a href="newtranslators.html">New Translator's Guide</a>
</li><li>
<a href="monotone.html">Monotone Guide</a>
</li><li>
<a href="dev-guidelines.html">Developer Guidelines</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/">Javadocs</a> (standard internet)
Note: always verify that javadocs are current by checking the release number.
</li><li>
Javadocs inside I2P:
<a href="http://i2p-javadocs.i2p">Server 1</a>
<a href="http://i2pdocs.str4d.i2p/i2p.i2p/javadoc/">Server 2</a>
<a href="http://echelon.i2p/javadoc/">Server 3</a>
<!--
<a href="http://docs.i2p2.i2p/javadoc/">Server 4 - out of date, incomplete</a>
-->
Note: always verify that javadocs are current by checking the release number.
</li><li>
<a href="ports.html">Ports used by I2P</a>
</li><li>
<a href="http://update.killyourtv.i2p/mtn/">Automatic updates to development builds inside I2P</a>
</li><li>
<a href="manualwrapper.html">Updating the wrapper manually</a>
</li><li>
<a href="http://forum.i2p2.de/">User forum</a>
</li><li>
<a href="http://zzz.i2p/">Developer forum inside I2P</a>
</li><li>
<a href="http://trac.i2p2.de/report/1">Bug tracker</a>
</li><li>
<a href="http://stats.i2p/cgi-bin/viewmtn/">Viewmtn inside I2P</a>.
</li><li>
<a href="https://github.com/i2p/i2p.i2p">I2P Source exported to GitHub</a>
</li><li>
<a href="http://git.repo.i2p/w/i2p.i2p.git">I2P Source Git Repo inside I2P</a>
</li><li>
<a href="https://www.transifex.net/projects/p/I2P/">Source translation at Transifex</a>
</li><li>
<a href="http://trac.i2p2.de/09roadmap">0.9 roadmap wiki</a> (not current)
</li><li>
<a href="roadmap.html">Old roadmap</a> (not current)
</li><li>
<a href="todo.html">To Do List</a> (not current)
</li></ul>
{% endblock %}

191
i2p2www/pages/site/docs/how/intro.html Normal file
View File

@@ -0,0 +1,191 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}A Gentle Introduction{% endtrans %}{% endblock %}
{% block content %}
<h2>{% trans %}A Gentle Introduction to How I2P Works{% endtrans %}</h2>
<p>{% trans -%}
I2P is a project to build, deploy, and maintain a network supporting secure and anonymous
communication. People using I2P are in control of the tradeoffs between anonymity, reliability,
bandwidth usage, and latency. There is no central point in the network on which pressure can be
exerted to compromise the integrity, security, or anonymity of the system. The network supports
dynamic reconfiguration in response to various attacks, and has been designed to make use of
additional resources as they become available. Of course, all aspects of the network are open and
freely available.
{%- endtrans %}</p>
<p>{% trans -%}
Unlike many other anonymizing networks, I2P doesn't try to provide anonymity by hiding the
originator of some communication and not the recipient, or the other way around. I2P is designed to
allow peers using I2P to communicate with each other anonymously &mdash; both sender and recipient
are unidentifiable to each other as well as to third parties. For example, today there are both
in-I2P web sites (allowing anonymous publishing / hosting) as well as HTTP proxies to the normal web
(allowing anonymous web browsing). Having the ability to run servers within I2P is essential, as it
is quite likely that any outbound proxies to the normal Internet will be monitored, disabled, or
even taken over to attempt more malicious attacks.
{%- endtrans %}</p>
<p>{% trans i2ptunnel=site_url('docs/applications/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
applications within I2P), a BitTorrent client ("I2PSnark"), or a distributed data store. With the
help of the <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.
{%- endtrans %}</p>
<p>{% trans threatmodel=site_url('docs/how/threatmodel') -%}
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
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 detection by a very powerful adversary, while others will try to evade a weaker
entity, <i>all on the same network</i>, where each one's messages are essentially indistinguishable
from the others.
{%- endtrans %}</p>
<h2>{% trans %}Why?{% endtrans %}</h2>
<p>{% trans networkcomparisons=site_url('docs/how/networkcomparisons') -%}
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
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') -%}
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
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="{{ netdb }}">network database</a> (using a modification of the Kademlia algorithm) for
distributing routing and contact information securely.
{%- endtrans %}</p>
<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/net.png') }}" alt="{% trans %}Network topology example{% endtrans %}" title="{% trans %}Network topology example{% endtrans %}" /></div>
<p>{% trans -%}
In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on
their local router. They each have a pair of 2-hop inbound tunnels per destination (labeled 1, 2, 3,
4, 5 and 6), and a small subset of each of those router's outbound tunnel pool is shown with 2-hop
outbound tunnels. For simplicity, Charlie's inbound tunnels and Dave's outbound tunnels are not
shown, nor are the rest of each router's outbound tunnel pool (typically stocked with a few tunnels
at a time). When Alice and Bob talk to each other, Alice sends a message out one of her (pink)
outbound tunnels targeting one of Bob's (green) inbound tunnels (tunnel 3 or 4). She knows to send
to those tunnels on the correct router by querying the network database, which is constantly updated
as new leases are authorized and old ones expire.
{%- endtrans %}</p>
<p>{% trans garlicrouting=site_url('docs/how/garlicrouting') -%}
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>
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.
{%- endtrans %}</p>
<p>{% trans peerselection=site_url('docs/how/peerselection') -%}
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
and is responsible for selecting appropriate peers to meet the anonymity, performance, and
reliability needs of the users, as described in the <a href="{{ peerselection }}">peer selection</a>
page.
{%- endtrans %}</p>
<p>{% trans crypto=site_url('docs/how/cryptography'), elgamalaes=site_url('docs/how/elgamalaes') -%}
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
negotiated connections with station to station authentication, and <a href="{{ elgamalaes
}}">ElGamal / AES+SessionTag</a>.
{%- endtrans %}</p>
<p>{% trans -%}
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 gateway to the tunnel endpoint), and inter router transport layer
encryption (e.g. the TCP transport uses AES256 with ephemeral keys).
{%- endtrans %}</p>
<p>{% trans -%}
End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release
0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice's router "a"
to Bob's router "h" remains. Notice the different use of terms! All data from a to h is end-to-end
encrypted, but the I2CP connection between the I2P router and the applications is not end-to-end
encrypted! A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the
applications running atop of I2P.
{%- endtrans %}</p>
<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') -%}
The specific use of these algorithms are outlined <a href="{{ cryptography }}">elsewhere</a>.
{%- endtrans %}</p>
<p>{% trans -%}
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 and mixing messages. These are currently planned for release 3.0, but garlic routed messages
with no delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow
people to set up and operate behind restricted routes (perhaps with trusted peers), as well as the
deployment of more flexible and anonymous transports.
{%- endtrans %}</p>
<p>{% trans netdb=site_url('docs/how/networkdatabase') -%}
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
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.
{%- endtrans %}</p>
<h2>{% trans %}When?{% endtrans %}</h2>
<p>{% trans roadmap=site_url('volunteer/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
'anonCommFramework' in April 2003, turning into I2P in July, with code being written in earnest
starting in August '03. I2P is currently under development, following the <a href="{{ roadmap
}}">roadmap</a>.
{%- endtrans %}</p>
<h2>{% trans %}Who?{% endtrans %}</h2>
<p>{% trans team=site_url('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,
writing I2P enabled applications, or documentation. The entire system is open source - the router
and most of the SDK are outright public domain with some BSD and Cryptix licensed code, while some
applications like I2PTunnel and I2PSnark are GPL. Almost everything is written in Java (1.5+),
though some third party applications are being written in Python and other languages. The code works
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) -%}
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') -%}
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>.
{%- endtrans %}</p>
{% endblock %}

198
i2p2www/pages/site/docs/how/networkcomparisons.html Normal file
View File

@@ -0,0 +1,198 @@
{% extends "global/layout.html" %}
{% block title %}I2P Compared to Tor and Freenet{% endblock %}
{% block content %}<p>There are a great many other applications and projects working on anonymous
communication and I2P has been inspired by much of their efforts. This is not
a comprehensive list of anonymity resources - both freehaven's
<a href="http://freehaven.net/anonbib/topic.html">Anonymity Bibliography</a>
and GNUnet's <a href="https://www.gnunet.org/links/">related projects</a>
serve that purpose well. That said, a few systems stand out for further
comparison. The following are discussed on this page:</p>
<ul>
<li>Tor / Onion Routing</li>
<li>Freenet</li>
</ul>
<p>The following are discussed on the <a href="othernetworks.html">other networks page:</a></p>
<ul>
<li>Morphmix and Tarzan</li>
<li>Mixminion / Mixmaster</li>
<li>JAP</li>
<li>MUTE / AntsP2P</li>
<li>Haystack</li>
</ul>
<p>The content of this page is subject to update, discussion and dispute, and we welcome comments and additions.
You may contribute an analysis by entering a
<a href="http://trac.i2p2.de/report/1">new ticket on trac.i2p2.de</a>.
</p>
<h2>Tor / Onion Routing</h2>
<i><a href="http://www.torproject.org/">[Tor]</a>
<a href="http://www.onion-router.net">[Onion Routing]</a></i>
<p>Tor and Onion Routing are both anonymizing proxy networks,
allowing people to tunnel out through their low latency mix
network. The two primary differences between Tor /
Onion-Routing and I2P are again related to differences in
the threat model and the out-proxy design (though Tor
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="{{ 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 -
once the communication leaves the mixnet, global passive
adversaries can more easily mount traffic analysis. In
addition, the outproxies have access to the cleartext
of the data transferred in both directions, and
outproxies are prone to abuse, along with all of the
other security issues we've come to know and love with
normal Internet traffic.</p>
<p>However, many people don't need to worry about those
situations, as they are outside their threat model. It
is, also, outside I2P's (formal) functional scope (if people want
to build outproxy functionality on top of an anonymous
communication layer, they can). In fact, some I2P users
currently take advantage of Tor to outproxy.</p>
<!--
<p>See also the
<a href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ComparisonI2P">the Tor FAQ</a>
for a Tor/I2P comparison from the Tor perspective.</p>
-->
<h3>Comparison of Tor and I2P Terminology</h3>
While Tor and I2P are similar in many ways, much of the terminology is different.
<table>
<tr><th align="left">Tor<th align="left">I2P
<tr><td>Cell<td>Message
<tr><td>Client<td>Router or Client
<tr><td>Circuit<td>Tunnel
<tr><td>Directory<td>NetDb
<tr><td>Directory Server<td>Floodfill Router
<tr><td>Entry Guards<td>Fast Peers
<tr><td>Entry Node<td>Inproxy
<tr><td>Exit Node<td>Outproxy
<tr><td>Hidden Service<td>Eepsite or Destination
<tr><td>Hidden Service Descriptor<td>LeaseSet
<tr><td>Introduction point<td>Inbound Gateway
<tr><td>Node<td>Router
<tr><td>Onion Proxy<td>I2PTunnel Client (more or less)
<tr><td>Relay<td>Router
<tr><td>Rendezvous Point<td>somewhat like Inbound Gateway + Outbound Endpoint
<tr><td>Router Descriptor<td>RouterInfo
<tr><td>Server<td>Router
</table>
<h3>Benefits of Tor over I2P</h3>
<ul>
<li>Much bigger user base; much more visibility in the academic and hacker communities; benefits from
formal studies of anonymity, resistance, and performance;
has a non-anonymous, visible, university-based leader</li>
<li>Has already solved some scaling issues I2P has yet to address</li>
<li>Has significant funding</li>
<li>Has more developers, including several that are funded</li>
<li>More resistant to state-level blocking due to TLS transport layer and bridges
(I2P has proposals for "full restricted routes" but these are not yet implemented)</li>
<li>Big enough that it has had to adapt to blocking and DOS attempts</li>
<li>Designed and optimized for exit traffic, with a large number of exit nodes</li>
<li>Better documentation, has formal papers and specifications, better website, many more translations</li>
<li>More efficient with memory usage</li>
<li>Tor client nodes have very low bandwidth overhead</li>
<li>Centralized control reduces the complexity at each
node and can efficiently address Sybil attacks</li>
<li>A core of high capacity nodes provides higher
throughput and lower latency</li>
<li>C, not Java (ewww)</li>
</ul>
<h3>Benefits of I2P over Tor</h3>
<ul>
<li>Designed and optimized for hidden services, which are much faster than in Tor</li>
<li>Fully distributed and self organizing</li>
<li>Peers are selected by continuously profiling and ranking performance,
rather than trusting claimed capacity</li>
<li>Floodfill peers ("directory servers") are varying and untrusted,
rather than hardcoded</li>
<li>Small enough that it hasn't been blocked or DOSed much, or at all</li>
<li>Peer-to-peer friendly</li>
<li>Packet switched instead of circuit switched
<ul>
<li>implicit transparent load balancing of messages
across multiple peers, rather than a single path</li>
<li>resilience vs. failures by running multiple
tunnels in parallel, plus rotating tunnels</li>
<li>scale each client's connections at O(1) instead
of O(N) (Alice has e.g. 2 inbound tunnels that are
used by all of the peers Alice is talking with,
rather than a circuit for each)</li>
</ul></li>
<li>Unidirectional tunnels instead of bidirectional
circuits, doubling the number of nodes a peer has to
compromise to get the same information.</li>
<li>Protection against detecting client activity, even
when an attacker is participating in the tunnel, as
tunnels are used for more than simply passing end
to end messages (e.g. netDb, tunnel management,
tunnel testing)</li>
<li>Tunnels in I2P are short lived, decreasing the number
of samples that an attacker can use to mount an
active attack with, unlike circuits in Tor, which are
typically long lived.</li>
<li>I2P APIs are designed specifically for anonymity and
security, while SOCKS is designed for functionality.</li>
<li>Essentially all peers participate in routing for others</li>
<li>The bandwidth overhead of being a full peer is low,
while in Tor, while client nodes don't require much
bandwidth, they don't fully participate in the mixnet.</li>
<li>Integrated automatic update mechanism</li>
<li>Both TCP and UDP transports</li>
<li>Java, not C (ewww)</li>
</ul>
<h3>Other potential benefits of I2P but not yet implemented</h3>
<p>...and may never be implemented, so don't count on them!</p>
<ul>
<li>Defense vs. message count analysis by garlic wrapping
multiple messages</li>
<li>Defense vs. long term intersection by adding delays
at various hops (where the delays are not discernible
by other hops)</li>
<li>Various mixing strategies at the tunnel level (e.g.
create a tunnel that will handle 500 messages / minute,
where the endpoint will inject dummy messages if there
are insufficient messages, etc)</li>
</ul>
<h2>Freenet</h2>
<i><a href="http://freenetproject.org/">[Freenet]</a></i>
<p>Freenet is a fully distributed, peer to peer anonymous publishing network, offering
secure ways to store data, as well as some approaches attempting to address the loads
of a flash flood. While Freenet is designed as a distributed data store, people have
built applications on top of it to do more generic anonymous communication, such as
static websites and message boards.</p>
<p>Compared to I2P, Freenet offers some substantial benefits - it is a distributed data
store, while I2P is not, allowing people to retrieve the content published by others
even when the publisher is no longer online. In addition, it should be able to
distribute popular data fairly efficiently. I2P itself does not and will not provide
this functionality. On the other hand, there is overlap for users who simply want to
communicate with each other anonymously through websites, message boards, file sharing
programs, etc. There have also been some attempts to develop a distributed data
store to run on top of I2P,
(most recently a port of <a href="http://tahoe-lafs.org/trac/tahoe-lafs">Tahoe-LAFS</a>)
but nothing is yet ready for general use.</p>
<p>However, even ignoring any implementations issues, there are some concerns
about Freenet's algorithms from both a scalability and anonymity perspective, owing
largely to Freenet's heuristic driven routing. The interactions of various techniques
certainly may successfully deter various attacks, and perhaps some aspects of the
routing algorithms will provide the hoped for scalability. Unfortunately, not much
analysis of the algorithms involved has resulted in positive results, but there is still
hope. At the very least, Freenet does provide substantial anonymity against an attacker
who does not have the resources necessary to analyze it further.</p>
{% endblock %}

764
i2p2www/pages/site/docs/how/networkdatabase.html Normal file
View File

@@ -0,0 +1,764 @@
{% extends "global/layout.html" %}
{% block title %}The Network Database{% endblock %}
{% block content %}
<p>
Updated June 2012, current as of router version 0.9
</p>
<h2>Overview</h2>
<p>
I2P's netDb is a specialized distributed database, containing
just two types of data - router contact information (<b>RouterInfos</b>) and destination contact
information (<b>LeaseSets</b>). Each piece of data is signed by the appropriate party and verified
by anyone who uses or stores it. In addition, the data has liveliness information
within it, allowing irrelevant entries to be dropped, newer entries to replace
older ones, and protection against certain classes of attack.
</p>
<p>
The netDb is distributed with a simple technique called "floodfill",
where a subset of all routers, called "floodfill routers", maintains the distributed database.
</p>
<h2 id="routerInfo">RouterInfo</h2>
<p>
When an I2P router wants to contact another router, they need to know some
key pieces of data - all of which are bundled up and signed by the router into
a structure called the "RouterInfo", which is distributed with the SHA256 of the router's identity
as the key. The structure itself contains:
</p>
<ul>
<li>The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA signing key, and a certificate)</li>
<li>The contact addresses at which it can be reached (e.g. TCP: example.org port 4108)</li>
<li>When this was published</li>
<li>A set of arbitrary text options</li>
<li>The signature of the above, generated by the identity's DSA signing key</li>
</ul>
<p>
The following text options, while not strictly required, are expected
to be present:
</p>
<ul>
<li><b>caps</b>
(Capabilities flags - used to indicate floodfill participation, approximate bandwidth, and perceived reachability)
<li><b>coreVersion</b>
(The core library version, always the same as the router version)
<li><b>netId</b> = 2
(Basic network compatibility - A router will refuse to communicate with a peer having a different netId)
<li><b>router.version</b>
(Used to determine compatibility with newer features and messages)
<li><b>stat_uptime</b> = 90m
(Always sent as 90m, for compatibility with an older scheme where routers published their actual uptime,
and only sent tunnel requests to peers whose was more than 60m)
</ul>
<p>
These values are used by other routers for basic decisions.
Should we connect to this router? Should we attempt to route a tunnel through this router?
The bandwidth capability flag, in particular, is used only to determine whether
the router meets a minimum threshold for routing tunnels.
Above the minimum threshold, the advertised bandwidth is not used or trusted anywhere
in the router, except for display in the user interface and for debugging and network analysis.
</p>
<p>
Additional text options include
a small number of statistics about the router's health, which are aggregated by
sites such as <a href="http://stats.i2p/">stats.i2p</a>
for network performance analysis and debugging.
These statistics were chosen to provide data crucial to the developers,
such as tunnel build success rates, while balancing the need for such data
with the side-effects that could result from revealing this data.
Current statistics are limited to:
</p>
<ul>
<li>Client and exploratory tunnel build success, reject, and timeout rates
<li>1 hour average number of participating tunnels
</ul>
<p>
The data
published can be seen in the router's user interface,
but is not used or trusted within the router.
As the network has matured, we have gradually removed most of the published
statistics to improve anonymity, and we plan to remove more in future releases.
</p>
<p>
<a href="common_structures_spec.html#struct_RouterInfo">RouterInfo specification</a>
</p>
<p>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/RouterInfo.html">RouterInfo Javadoc</a>
</p>
<h3>RouterInfo Expiration</h3>
<p>
RouterInfos have no set expiration time.
Each router is free to maintain its own local policy to trade off the frequency of RouterInfo lookups
with memory or disk usage.
In the current implementation, there are the following general policies:
</p>
<ul>
<li>There is no expiration during the first hour of uptime, as the persistent stored data may be old.</li>
<li>There is no expiration if there are 25 or less RouterInfos.</li>
<li>As the number of local RouterInfos grows, the expiration time shrinks, in an attempt to maintain
a reasonable number RouterInfos. The expiration time with less than 120 routers is 72 hours,
while expiration time with 300 routers is around 30 hours.</li>
<li>RouterInfos containing <a href="udp.html">SSU</a> introducers expire in about an hour, as
the introducer list expires in about that time.</li>
<li>Floodfills use a short expiration time (1 hour) for all local RouterInfos, as valid RouterInfos will
be frequently republished to them.</li>
</ul>
<h3>RouterInfo Persistent Storage</h3>
<p>
RouterInfos are periodically written to disk so that they are available after a restart.
</p>
<h2 id="leaseSet">LeaseSet</h2>
<p>
The second piece of data distributed in the netDb is a "LeaseSet" - documenting
a group of <b>tunnel entry points (leases)</b> for a particular client destination.
Each of these leases specify the following information:
<ul>
<li>The tunnel gateway router (by specifying its identity)</li>
<li>The tunnel ID on that router to send messages with (a 4 byte number)</li>
<li>When that tunnel will expire.</li>
</ul>
The LeaseSet itself is stored in the netDb under
the key derived from the SHA256 of the destination.
</p>
<p>
In addition to these leases, the LeaseSet includes:
<ul>
<li>The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA signing key and a certificate)</li>
<li>Additional encryption public key: used for end-to-end encryption of garlic messages</li>
<li>Additional signing public key: intended for LeaseSet revocation, but is currently unused.</li>
<li>Signature of all the LeaseSet data, to make sure the Destination published the LeaseSet.</li>
</ul>
</p>
<p>
<a href="common_structures_spec.html#struct_Lease">Lease specification</a>
<br />
<a href="common_structures_spec.html#struct_LeaseSet">LeaseSet specification</a>
</p>
<p>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/Lease.html">Lease Javadoc</a>
<br />
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/LeaseSet.html">LeaseSet Javadoc</a>
</p>
<h3 id="unpublished">Unpublished LeaseSets</h3>
<p>
A LeaseSet for a destination used only for outgoing connections is <i>unpublished</i>.
It is never sent for publication to a floodfill router.
"Client" tunnels, such as those for web browsing and IRC clients, are unpublished.
Servers will still be able to send messages back to those unpublished destinations,
because of <a href="#leaseset_storage_peers">I2NP storage messages</a>.
</p>
<h3 id="revoked">Revoked LeaseSets</h3>
<p>
A LeaseSet may be <i>revoked</i> by publishing a new LeaseSet with zero leases.
Revocations must be signed by the additional signing key in the LeaseSet.
Revocations are not fully implemented, and it is unclear if they have any practical use.
This is the only planned use for that signing key, so it is currently unused.
</p>
<h3 id="encrypted">Encrypted LeaseSets</h3>
<p>
In an <i>encrypted</i> LeaseSet, all Leases are encrypted with a separate DSA key.
The leases may only be decoded, and thus the destination may only be contacted,
by those with the key.
There is no flag or other direct indication that the LeaseSet is encrypted.
Encrypted LeaseSets are not widely used, and it is a topic for future work to
research whether the user interface and implementation of encrypted LeaseSets could be improved.
</p>
<h3>LeaseSet Expiration</h3>
<p>
All Leases (tunnels) are valid for 10 minutes; therefore, a LeaseSet expires
10 minutes after the earliest creation time of all its Leases.
</p>
<h3>LeaseSet Persistent Storage</h3>
<p>
There is no persistent storage of LeaseSet data since they expire so quickly.
</p>
<h2 id="bootstrap">Bootstrapping</h2>
<p>
The netDb is decentralized, however you do need at
least one reference to a peer so that the integration process
ties you in. This is accomplished by "reseeding" your router with the RouterInfo
of an active peer - specifically, by retrieving their <code>routerInfo-$hash.dat</code>
file and storing it in your <code>netDb/</code> directory. Anyone can provide
you with those files - you can even provide them to others by exposing your own
netDb directory. To simplify the process,
volunteers publish their netDb directories (or a subset) on the regular (non-i2p) network,
and the URLs of these directories are hardcoded in I2P.
When the router starts up for the first time, it automatically fetches from
one of these URLs, selected at random.
</p>
<h2 id="floodfill">Floodfill</h2>
<p>
The floodfill netDb is a simple distributed storage mechanism.
The storage algorithm is simple: send the data to the closest peer that has advertised itself
as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them
for the entry to be sent, verifying its proper insertion / distribution. If the
verification peer doesn't reply, or they don't have the entry, the sender
repeats the process. When the peer in the floodfill netDb receives a netDb
store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers.
The peers selected are the ones closest (according to the <a href="#kademlia_closeness">XOR-metric</a>) to a specific key.
</p>
<p>
Determining who is part of the floodfill netDb is trivial - it is exposed in each
router's published routerInfo as a capability.
</p>
<p>
Floodfills have no central authority and do not form a "consensus" -
they only implement a simple DHT overlay.
</p>
<h3 id="opt-in">Floodfill Router Opt-in</h3>
<p>
Unlike Tor, where the directory servers are hardcoded and trusted,
and operated by known entities,
the members of the I2P floodfill peer set need not be trusted, and
change over time.
</p>
<p>
To increase reliability of the netDb, and minimize the impact
of netDb traffic on a router, floodfill is automatically enabled
only on routers that are configured with high bandwidth limits.
Routers with high bandwidth limits (which must be manually configured,
as the default is much lower) are presumed to be on lower-latency
connections, and are more likely to be available 24/7.
The current minimum share bandwidth for a floodfill router is 128 KBytes/sec.
</p>
<p>
In addition, a router must pass several additional tests for health
(outbound message queue time, job lag, etc.) before floodfill operation is
automatically enabled.
</p>
<p>
With the current rules for automatic opt-in, approximately 6% of
the routers in the network are floodfill routers.
</p>
<p>
While some peers are manually configured to be floodfill,
others are simply high-bandwidth routers who automatically volunteer
when the number of floodfill peers drops below a threshold.
This prevents any long-term network damage from losing most or all
floodfills to an attack.
In turn, these peers will un-floodfill themselves when there are
too many floodfills outstanding.
</p>
<h3>Floodfill Router Roles</h3>
<p>
A floodfill router's only services that are in addition to those of non-floodfill routers
are in accepting netDb stores and responding to netDb queries.
Since they are generally high-bandwidth, they are more likely to participate in a high number of tunnels
(i.e. be a "relay" for others), but this is not directly related to their distributed database services.
</p>
<a name="kademlia_closeness"><h2 id="kad">Kademlia Closeness Metric</h2></a>
<p>
The netDb uses a simple Kademlia-style XOR metric to determine closeness.
The SHA256 hash of the key being looked up or stored is XOR-ed with
the hash of the router in question to determine closeness.
A modification to this algorithm is done to increase the costs of <a href="#sybil-partial">Sybil attacks</a>.
Instead of the SHA256 hash of the key being looked up of stored, the SHA256 hash is taken
of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd).
</p>
<h2 id="delivery">Storage, Verification, and Lookup Mechanics</h2>
<h3>RouterInfo Storage to Peers</h3>
<p>
<a href="i2np.html">I2NP</a> DatabaseStoreMessages containing the local RouterInfo are exchanged with peers
as a part of the initialization of a
<a href="ntcp.html">NTCP</a>
or
<a href="udp.html">SSU</a>
transport connection.
</p>
<a name="leaseset_storage_peers"><h3>LeaseSet Storage to Peers</h3></a>
<p>
<a href="i2np.html">I2NP</a> DatabaseStoreMessages containing the local LeaseSet are periodically exchanged with peers
by bundling them in a garlic message along with normal traffic from the related Destination.
This allows an initial response, and later responses, to be sent to an appropriate Lease,
without requiring any LeaseSet lookups, or requiring the communicating Destinations to have published LeaseSets at all.
</p>
<h3>RouterInfo Storage to Floodfills</h3>
<p>
A router publishes its own RouterInfo by directly connecting to a floodfill router
and sending it a <a href="i2np.html">I2NP</a> DatabaseStoreMessage
with a nonzero Reply Token. The message is not end-to-end garlic encrypted,
as this is a direct connection, so there are no intervening routers
(and no need to hide this data anyway).
The floodfill router replies with a
<a href="i2np.html">I2NP</a> DeliveryStatusMessage,
with the Message ID set to the value of the Reply Token.
</p>
<h3>LeaseSet Storage to Floodfills</h3>
<p>
Storage of LeaseSets is much more sensitive than for RouterInfos, as a router
must take care that the LeaseSet cannot be associated with the router.
</p>
<p>
A router publishes a local LeaseSet by
sending a <a href="i2np.html">I2NP</a> DatabaseStoreMessage
with a nonzero Reply Token over an outbound client tunnel for that Destination.
The message is end-to-end garlic encrypted using the Destination's Session Key Manager,
to hide the message from the tunnel's outbound endpoint.
The floodfill router replies with a
<a href="i2np.html">I2NP</a> DeliveryStatusMessage,
with the Message ID set to the value of the Reply Token.
This message is sent back to one of the client's inbound tunnels.
</p>
<h3>Flooding</h3>
<p>
After a floodfill router receives a DatabaseStoreMessage containing a
valid RouterInfo or LeaseSet which is newer than that previously stored in its
local NetDb, it "floods" it.
To flood a NetDb entry, it looks up the 7 floodfill routers closest to the key
of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.)
</p>
<p>
It then directly connects to each of the 7 peers
and sends it a <a href="i2np.html">I2NP</a> DatabaseStoreMessage
with a zero Reply Token. The message is not end-to-end garlic encrypted,
as this is a direct connection, so there are no intervening routers
(and no need to hide this data anyway).
The other routers do not reply or re-flood, as the Reply Token is zero.
</p>
<h3 id="lookup">RouterInfo and LeaseSet Lookup</h3>
<p>
The <a href="i2np.html">I2NP</a> DatabaseLookupMessage is used to request a netdb entry from a floodfill router.
Lookups are sent out one of the router's outbound exploratory tunnels.
The replies are specified to return via one of the router's inbound exploratory tunnels.
</p>
<p>
Lookups are generally sent to the two "good" (the connection doesn't fail) floodfill routers closest to the requested key, in parallel.
</p>
<p>
If the key is found locally by the floodfill router, it responds with a
<a href="i2np.html">I2NP</a> DatabaseStoreMessage.
If the key is not found locally by the floodfill router, it responds with a
<a href="i2np.html">I2NP</a> DatabaseSearchReplyMessage
containing a list of other floodfill routers close to the key.
</p>
<p>
Lookups are not encrypted and thus are vulnerable to snooping by the outbound endpoint
(OBEP) of the client tunnel.
</p>
<p>
As the requesting router does not reveal itself, there is no recipient public key for the floodfill router to
encrypt the reply with. Therefore, the reply is exposed to the inbound gateway (IBGW)
of the inbound exploratory tunnel.
An appropriate method of encrypting the reply is a topic for future work.
</p>
<p>
(Reference:
<a href="http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf">Hashing it out in Public</a> Sections 2.2-2.3 for terms below in italics)
</p>
<p>
Due to the relatively small size of the network and the flooding redundancy of 8x,
lookups are usually O(1) rather than O(log n) --
a router is highly likely to know a floodfill router close enough to the key to get the answer on the first try.
In releases prior to 0.8.9, routers used a lookup redundancy of two
(that is, two lookups were performed in parallel to different peers), and
neither <i>recursive</i> nor <i>iterative</i> routing for lookups was implemented.
Queries were sent through <i>multiple routes simultaneously</i>
to <i>reduce the chance of query failure</i>.
</p>
<p>
As of release 0.8.9, <i>iterative lookups</i> are implemented with no lookup redundancy.
This is a more efficient and reliable lookup that will work much better
when not all floodfill peers are known, and it removes a serious
limitation to network growth. As the network grows and each router knows only a small
subset of the floodfill peers, lookups will become O(log n).
Even if the peer does not return references closer to the key, the lookup continues with
the next-closest peer, for added robustness, and to prevent a malicious floodfill from
black-holing a part of the key space. Lookups continue until a total lookup timeout is reached,
or the maximum number of peers is queried.
</p>
<p>
<i>Node IDs</i> are <i>verifiable</i> in that we use the router hash directly as both the node ID and the Kademlia key.
Incorrect responses that are not closer to the search key are generally ignored.
Given the current size of the network, a router has
<i>detailed knowledge of the neighborhood of the destination ID space</i>.
</p>
<h3>RouterInfo Storage Verification</h3>
<p>
To verify a storage was successful, a router simply waits about 10 seconds,
then sends a lookup to another floodfill router close to the key
(but not the one the store was sent to).
Lookups sent out one of the router's outbound exploratory tunnels.
Lookups are end-to-end garlic encrypted to prevent snooping by the outbound endpoint(OBEP).
</p>
<h3>LeaseSet Storage Verification</h3>
<p>
To verify a storage was successful, a router simply waits about 10 seconds,
then sends a lookup to another floodfill router close to the key
(but not the one the store was sent to).
Lookups sent out one of the outbound client tunnels for the destination of the LeaseSet being verified.
To prevent snooping by the OBEP of the outbound tunnel,
lookups are end-to-end garlic encrypted.
The replies are specified to return via one of the client's inbound tunnels.
</p>
<p>
As for regular lookups, the reply is unencrypted,
thus exposing the reply to the inbound gateway (IBGW) of the reply tunnel, and
an appropriate method of encrypting the reply is a topic for future work.
As the IBGW for the reply is one of the gateways published in the LeaseSet,
the exposure is minimal.
</p>
<h3>Exploration</h3>
<p>
<i>Exploration</i> is a special form of netdb lookup, where a router attempts to learn about
new routers.
It does this by sending a floodfill router a <a href="i2np.html">I2NP</a> DatabaseLookupMessage, looking for a random key.
As this lookup will fail, the floodfill would normally respond with a
<a href="i2np.html">I2NP</a> DatabaseSearchReplyMessage containing hashes of floodfill routers close to the key.
This would not be helpful, as the requesting router probably already knows those floodfills,
and it would be impractical to add ALL floodfill routers to the "don't include" field of the lookup.
For an exploration query, the requesting router adds a router hash of all zeros to the
"don't include" field of the DatabaseLookupMessage.
The floodfill will then respond only with non-floodfill routers close to the requested key.
</p>
<h3>Notes on Lookup Responses</h3>
<p>
The response to a lookup request is either a Database Store Message (on success) or a
Database Search Reply Message (on failure). The DSRM contains a 'from' router hash field
to indicate the source of the reply; the DSM does not.
The DSRM 'from' field is unauthenticated and may be spoofed or invalid.
There are no other response tags. Therefore, when making multiple requests in parallel, it is
difficult to monitor the performance of the various floodfill routers.
</p>
<h2 id="multihome">MultiHoming</h2>
<p>
Destinations may be hosted on multiple routers simultaneously, by using the same
private and public keys (traditionally stored in eepPriv.dat files).
As both instances will periodically publish their signed LeaseSets to the floodfill peers,
the most recently published LeaseSet will be returned to a peer requesting a database lookup.
As LeaseSets have (at most) a 10 minute lifetime, should a particular instance go down,
the outage will be 10 minutes at most, and generally much less than that.
The multihoming function has been verified and is in use by several services on the network.
</p>
<h2 id="threat">Threat Analysis</h2>
<p>
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
creating one or more floodfill routers and crafting them to offer
bad, slow, or no responses.
Some scenarios are discussed below.
</p>
<h3>General Mitigation Through Growth</h3>
<p>
There are currently almost 100 floodfill routers in the network.
Most of the following attacks will become more difficult, or have less impact,
as the network size and number of floodfill routers increase.
</p>
<h3>General Mitigation Through Redundancy</h3>
<p>
Via flooding, all netdb entries are stored on the 8 floodfill routers closest to the key.
</p>
<h3>Forgeries</h3>
<p>
All netdb entries are signed by their creators, so no router may forge a
RouterInfo or LeaseSet.
</p>
<h3>Slow or Unresponsive</h3>
<p>
Each router maintains an expanded set of statistics in the
<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>
<ul>
<li>Average response time
<li>Percentage of queries answered with the data requested
<li>Percentage of stores that were successfully verified
<li>Last successful store
<li>Last successful lookup
<li>Last response
</ul>
<p>
Each time a router needs to make a determination on which floodfill router is closest to a key,
it uses these metrics to determine which floodfill routers are "good".
The methods, and thresholds, used to determine "goodness" are relatively new, and
are subject to further analysis and improvement.
While a completely unresponsive router will quickly be identified and avoided,
routers that are only sometimes malicious may be much harder to deal with.
</p>
<h3 id="sybil">Sybil Attack (Full Keyspace)</h3>
<p>
An attacker may mount a
<a href="http://citeseer.ist.psu.edu/douceur02sybil.html">Sybil attack</a>
by creating a large number of floodfill routers spread throughout the keyspace.
</p>
<p>
(In a related example, a researcher recently created a
<a href="http://blog.torproject.org/blog/june-2010-progress-report">large number of Tor relays</a>.)
If successful, this could be an effective DOS attack on the entire network.
</p>
<p>
If the floodfills are not sufficiently misbehaving to be marked as "bad" using the peer profile
metrics described above, this is a difficult scenario to handle.
Tor's response can be much more nimble in the relay case, as the suspicious relays
can be manually removed from the consensus.
Some possible responses for the I2P network are listed below, however none of them is completely satisfactory:
</p>
<ul>
<li>Compile a list of bad router hashes or IPs, and announce the list through various means
(console news, website, forum, etc.); users would have to manually download the list and
add it to their local "blacklist"
<li>Ask everyone in the network to enable floodfill manually (fight Sybil with more Sybil)
<li>Release a new software version that includes the hardcoded "bad" list
<li>Release a new software version that improves the peer profile metrics and thresholds,
in an attempt to automatically identify the "bad" peers
<li>Add software that disqualifies floodfills if too many of them are in a single IP block
<li>Implement an automatic subscription-based blacklist controlled by a single individual or group.
This would essentially implement a portion of the Tor "consensus" model.
Unfortunately it would also give a single individual or group the power to
block participation of any particular router or IP in the network,
or even to completely shutdown or destroy the entire network.
</ul>
<p>
This attack becomes more difficult as the network size grows.
</p>
<h3 id="sybil-partial">Sybil Attack (Partial Keyspace)</h3>
<p>
An attacker may mount a
<a href="http://citeseer.ist.psu.edu/douceur02sybil.html">Sybil attack</a>
by creating a small number (8-15) of floodfill routers clustered closely in the keyspace,
and distribute the RouterInfos for these routers widely.
Then, all lookups and stores for a key in that keyspace would be directed
to one of the attacker's routers.
If successful, this could be an effective DOS attack on a particular eepsite, for example.
</p>
<p>
As the keyspace is indexed by the cryptographic (SHA256) Hash of the key,
an attacker must use a brute-force method to repeatedly generate router hashes
until he has enough that are sufficiently close to the key.
The amount of computational power required for this, which is dependent on network
size, is unknown.
</p>
<p>
As a partial defense against this attack,
the algorithm used to determine Kademlia "closeness" varies over time.
Rather than using the Hash of the key (i.e. H(k)) to determine closeness,
we use the Hash of the key appended with the current date string, i.e. H(k + YYYYMMDD).
A function called the "routing key generator" does this, which transforms the original key into a "routing key".
In other words, the entire netdb keyspace "rotates" every day at UTC midnight.
Any partial-keyspace attack would have to be regenerated every day, for
after the rotation, the attacking routers would no longer be close
to the target key, or to each other.
</p>
<p>
This attack becomes more difficult as the network size grows.
</p>
<p>
One consequence of daily keyspace rotation is that the distributed network database
may become unreliable for a few minutes after the rotation --
lookups will fail because the new "closest" router has not received a store yet.
The extent of the issue, and methods for mitigation
(for example netdb "handoffs" at midnight)
are a topic for further study.
</p>
<h3>Bootstrap Attacks</h3>
<p>
An attacker could attempt to boot new routers into an isolated
or majority-controlled network by taking over a reseed website,
or tricking the developers into adding his reseed website
to the hardcoded list in the router.
</p>
<p>
Several defenses are possible, and most of these are planned:
</p>
<ul>
<li>Disallow fallback from HTTPS to HTTP for reseeding.
A MITM attacker could simply block HTTPS, then respond to the HTTP.
<li>Changing the reseed task to fetch a subset of RouterInfos from
each of several reseed sites rather than using only a single site
<li>Creating an out-of-network reseed monitoring service that
periodically polls reseed websites and verifies that the
data are not stale or inconsistent with other views of the network
<li>Bundling reseed data in the installer
</ul>
<h3>Query Capture</h3>
<p>
See also <a href="#lookup">lookup</a>
(Reference:
<a href="http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf">Hashing it out in Public</a> Sections 2.2-2.3 for terms below in italics)
</p>
<p>
Similar to a bootstrap attack, an attacker using a floodfill router could attempt to "steer"
peers to a subset of routers controlled by him by returning their references.
</p>
<p>
This is unlikely to work via exploration, because exploration is a low-frequency task.
Routers acquire a majority of their peer references through normal tunnel building activity.
Exploration results are generally limited to a few router hashes,
and each exploration query is directed to a random floodfill router.
</p>
<p>
As of release 0.8.9, <i>iterative lookups</i> are implemented.
For floodfill router references returned in a
<a href="i2np.html">I2NP</a> DatabaseSearchReplyMessage
response to a lookup,
these references are followed if they are closer (or the next closest) to the lookup key.
The requesting router does not trust that the references are
closer to the key (i.e. they are <i>verifiably correct</i>.
The lookup also does not stop when no closer key is found, but continues by querying the
next-closet node, until the timeout or maximum number of queries is reached.
This prevents a malicious floodfill from black-holing a part of the key space.
Also, the daily keyspace rotation requires an attacker to regenerate a router info
within the desired key space region.
This design ensures that the query capture attack described in
<a href="http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf">Hashing it out in Public</a>
is much more difficult.
</p>
<h3>DHT-Based Relay Selection</h3>
<p>
(Reference:
<a href="http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf">Hashing it out in Public</a> Section 3)
</p>
<p>
This doesn't have much to do with floodfill, but see
the <a href="{{ site_url('docs/how/peerselection') }}">peer selection page</a>
for a discussion of the vulnerabilities of peer selection for tunnels.
</p>
<h3>Information Leaks</h3>
<p>
(Reference:
<a href="https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf">In Search of an Anonymous and Secure Lookup</a> Section 3)
</p>
<p>
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="{{ 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>
<p>
Some of this may actually be more interesting when the I2P network gets much larger.
Right now, each router knows a large proportion of the network, so looking up a particular
Router Info in the network database is not strongly indicative of a future intent to use
that router in a tunnel. Perhaps when the network is 100 times larger, the lookup may be
more correlative. Of course, a larger network makes a Sybil attack that much harder.
</p>
<p>
However, the general issue of DHT information leakage in I2P needs further investigation.
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="{{ 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.
</p>
<h2 id="history">History</h2>
<p>
<a href="netdb_discussion.html">Moved to the netdb discussion page</a>.
</p>
<h2 id="future">Future Work</h2>
<p>
End-to-end encryption of additional netDb lookups and responses.
</p>
<p>
Better methods for tracking lookup responses.
</p>
{% endblock %}

259
i2p2www/pages/site/docs/how/peerselection.html Normal file
View File

@@ -0,0 +1,259 @@
{% extends "global/layout.html" %}
{% block title %}Peer Profiling and Selection{% endblock %}
{% block content %}
Updated July 2010 for release 0.8
<h2>Overview</h2>
<h3>Peer Profiling</h3>
<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="{{ 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="{{ site_url('docs/how/networkdatabase') }}">network database</a> page
</ol>
<h3>Peer Selection</h3>
<p><b>Peer selection</b> is the process of choosing which routers
on the network we want to relay our messages to go through (which peers will we
ask to join our tunnels). To accomplish this, we keep track of how each
peer performs (the peer's "profile") and use that data to estimate how
fast they are, how often they will be able to accept our requests, and
whether they seem to be overloaded or otherwise unable to perform what
they agree to reliably.</p>
<p>
Unlike some other anonymous networks, in I2P,
claimed bandwidth is untrusted and is <b>only</b> used to avoid those peers
advertising very low bandwidth insufficient for routing tunnels.
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="{{ site_url('docs/how/threatmodel') }}#timing">timing attacks</a>
more difficult.
</p>
<p>
Peer selection is done quite frequently, as a router may maintain a large number
of client and exploratory tunnels, and a tunnel lifetime is only 10 minutes.
<h3>Further Information</h3>
<p>
For more information see the paper
<a href="{{ url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') }}">Peer Profiling and Selection in the I2P Anonymous Network</a>
presented at
<a href="http://www.pet-con.org/index.php/PET_Convention_2009.1">PET-CON 2009.1</a>.
See <a href="#notes">below</a> for notes on minor changes since the paper was published.
</p>
<h2>Profiles</h2>
<p>Each peer has a set of data points collected about them, including statistics
about how long it takes for them to reply to a network database query, how
often their tunnels fail, and how many new peers they are able to introduce
us to, as well as simple data points such as when we last heard from them or
when the last communication error occurred. The specific data points gathered
can be found in the <a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/PeerProfile.html">code</a>
</p>
<p>
Profiles are fairly small, a few KB. To control memory usage, the profile expiration time
lessens as the number of profiles grows.
Profiles are kept in memory until router shutdown, when they are written to disk.
At startup, the profiles are read so the router need not reinitialize all profiles,
thus allowing a router to quickly re-integrate into the network after startup.
</p>
<h2>Peer Summaries</h2>
<p>While the profiles themselves can be considered a summary of a peer's
performance, to allow for effective peer selection we break each summary down
into four simple values, representing the peer's speed, its capacity, how well
integrated into the network it is, and whether it is failing.</p>
<h3>Speed</h3>
<p>The speed calculation
simply goes through the profile and estimates how much data we can
send or receive on a single tunnel through the peer in a minute. For this estimate it just looks at
performance in the previous minute.
</p>
<h3 id="capacity">Capacity</h3>
<p>The capacity calculation
simply goes through the profile and estimates how many tunnels the peer
would agree to participate in over a given time period. For this estimate it looks at
how many tunnel build requests
the peer has accepted, rejected, and dropped, and how many
of the agreed-to tunnels later failed.
While the calculation is time-weighted so that recent activity counts more than later activity,
statistics up to 48 hours old may be included.
</p><p>
Recognizing and avoiding unreliable and unreachable
peers is critically important.
Unfortunately, as the tunnel building and testing require the participation of several peers,
it is difficult to positively identify the cause of a dropped build request or test failure.
The router assigns a probability of failure to each of the
peers, and uses that probability in the capacity calculation.
Drops and test failures are weighted much higher than rejections.
</p>
<h2>Peer organization</h2>
<p>As mentioned above, we drill through each peer's profile to come up with a
few key calculations, and based upon those, we organize each peer into three
groups - fast, high capacity, and standard.
<p>The groupings are not mutually exclusive, nor are they unrelated: <ul>
<li>A peer is considered "high capacity" if its capacity calculation meets or
exceeds the median of all peers. </li>
<li>A peer is considered "fast" if they are already "high capacity" and their
speed calculation meets or exceeds the median of all peers.</li>
<li>A peer is considered "standard" if it is not "high capacity"</li>
</ul>
These groupings are implemented in the router's <a
href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/ProfileOrganizer.html">ProfileOrganizer</a>.
<h3>Group size limits</h3>
The size of the groups may be limited.
<ul>
<li>The fast group is limited to 30 peers.
If there would be more, only the ones with the highest speed rating are placed in the group.
<li>The high capacity group is limited to 75 peers (including the fast group)
If there would be more, only the ones with the highest capacity rating are placed in the group.
<li>The standard group has no fixed limit, but is somewhat smaller than the number of RouterInfos
stored in the local network database.
On an active router in today's network, there may be about 1000 RouterInfos and 500 peer profiles
(including those in the fast and high capacity groups)
</ul>
<h2>Recalculation and Stability</h2>
Summaries are recalculated, and peers are resorted into groups, every 45 seconds.
<p>
The groups tend to be fairly stable, that is, there is not much "churn" in the rankings
at each recalculation.
Peers in the fast and high capacity groups get more tunnels build through them, which increases their speed and capacity ratings,
which reinforces their presence in the group.
<h2>Peer Selection</h2>
The router selects peers from the above groups to build tunnels through.
<h3>Peer Selection for Client Tunnels</h3>
Client tunnels are used for application traffic, such as for HTTP proxies and web servers.
<p>
To reduce the susceptibility to <a href="http://blog.torproject.org/blog/one-cell-enough">some attacks</a>,
and increase performance,
peers for building client tunnels are chosen randomly from the smallest group, which is the "fast" group.
There is no bias toward selecting peers that were previously participants in a tunnel for the same client.
<h3>Peer Selection for Exploratory Tunnels</h3>
Exploratory tunnels are used for router administrative purposes, such as network database traffic
and testing client tunnels.
Exploratory tunnels are also used to contact previously unconnected routers, which is why
they are called "exploratory".
These tunnels are usually low-bandwidth.
<p>
Peers for building exploratory tunnels are generally chosen randomly from the standard group.
If the success rate of these build attempts is low compared to the client tunnel build success rate,
the router will select a weighted average of peers randomly from the high capacity group instead.
This helps maintain a satisfactory build success rate even when network performance is poor.
There is no bias toward selecting peers that were previously participants in an exploratory tunnel.
<p>
As the standard group includes a very large subset of all peers the router knows about,
exploratory tunnels are essentially built through a random selection of all peers,
until the build success rate becomes too low.
<h3>Restrictions</h3>
To prevent some simple attacks, and for performance, there are the following restrictions:
<ul>
<li>
Two peers from the same /16 IP space may not be in the same tunnel.
<li>
A peer may participate in a maximum of 33% of all tunnels created by the router.
<li>
Peers with extremely low bandwidth are not used.
<li>
Peers for which a recent connection attempt failed are not used.
</ul>
<h3>Peer Ordering in Tunnels</h3>
Peers are ordered within tunnels to
to deal with the <a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">predecessor
attack</a> <a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">(2008
update)</a>.
More information is on the <a href="tunnel-alt.html#ordering">tunnel page</a>.
<h2>Future Work</h2>
<ul>
<li>
Continue to analyze an tune speed and capacity calculations as necessary
<li>
Implement a more aggressive ejection strategy if necessary to control memory usage as the network grows
<li>
Evaluate group size limits
<li>
Use GeoIP data to include or exclude certain peers, if configured
</ul>
<h2 id="notes">Notes</h2>
For those reading the paper
<a href="{{ url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') }}">Peer Profiling and Selection in the I2P Anonymous Network</a>,
please keep in mind the following minor changes in I2P since the paper's publication:
<ul>
<li>The Integration calculation is still not used
<li>In the paper, "groups" are called "tiers"
<li>The "Failing" tier is no longer used
<li>The "Not Failing" tier is now named "Standard"
</ul>
<h2>References</h2>
<ul>
<li>
<a href="{{ url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') }}">Peer Profiling and Selection in the I2P Anonymous Network</a>
<li>
<a href="http://blog.torproject.org/blog/one-cell-enough">One Cell Enough</a>
<li>
<a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#EntryGuards">Tor Entry Guards</a>
<li>
<a href="http://freehaven.net/anonbib/#murdoch-pet2007">Murdoch 2007 Paper</a>
<li>
<a href="http://www.crhc.uiuc.edu/~nikita/papers/tuneup-cr.pdf">Tune-up for Tor</a>
<li>
<a href="http://systems.cs.colorado.edu/~bauerk/papers/wpes25-bauer.pdf">Low-resource Routing Attacks Against Tor</a>
</ul>
{% endblock %}

737
i2p2www/pages/site/docs/how/threatmodel.html Normal file
View File

@@ -0,0 +1,737 @@
{% extends "global/layout.html" %}
{% block title %}I2P's Threat Model{% endblock %}
{% block content %}
Updated November 2010, current as of router version 0.8.1
<h2>What do we mean by "anonymous"?</h2>
<p>Your level of anonymity can be described as "how hard it is for someone
to find out information you don't want them to know?" - who you are, where
you are located, who you communicate with, or even when you communicate.
"Perfect" anonymity is not a useful concept here - software will not make
you indistinguishable from people that don't use computers or who are not on
the Internet. Instead, we are working to provide sufficient anonymity to meet the
real needs of whomever we can - from those simply browsing websites, to those exchanging
data, to those fearful of discovery by powerful organizations or states.</p>
<p>The question of whether I2P provides sufficient anonymity for your
particular needs is a hard one, but this page will hopefully assist in
answering that question by exploring how I2P operates under various attacks
so that you may decide whether it meets your needs.</p>
<p>We welcome further research and analysis on I2P's resistance to the threats described below.
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="{{ 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
path that messages will be sent out (the outbound tunnel), and the message
recipient explicitly defines the path that messages will be received on (the
inbound tunnel).
</li>
<li><b>I2P has no official entry and exit points</b> - all peers fully participate in the
mix, and there are no network layer in- or out-proxies (however, at the
application layer, a few proxies do exist)</li>
<li><b>I2P is fully distributed</b> - there are no central controls or authorities.
One could modify some routers to operate mix cascades (building tunnels and giving
out the keys necessary to control the forwarding at the tunnel endpoint) or directory
based profiling and selection, all without breaking compatibility with the rest of
the network, but doing so is of course not necessary (and may even harm one's
anonymity).</li>
</ul>
<p>
We have documented plans to implement
<a href="todo#stop">nontrivial delays</a> and <a href="todo#batching">batching strategies</a>
whose existence is only known to the particular hop or tunnel gateway that
receives the message, allowing a mostly low latency mixnet to provide cover
traffic for higher latency communication (e.g. email).
However we are aware that significant delays are required to provide meaningful
protection, and that implementation of such delays will be a significant challenge.
It is not clear at this time whether we will actually implement these delay features.
</p><p>
In theory, routers along the message path may inject an
arbitrary number of hops before forwarding the message to the next peer, though
the current implementation does not.
</p>
<h2>The Threat Model (Attacks)</h2>
<p>
I2P design started in 2003, not long after the advent of
<a href="http://www.onion-router.net">[Onion Routing]</a>,
<a href="http://freenetproject.org/">[Freenet]</a>, and
<a href="http://www.torproject.org/">[Tor]</a>.
Our design benefits substantially from the research published around that time.
I2P uses several onion routing techniques, so we continue to benefit
from the significant academic interest in Tor.
</p><p>
Taking from the attacks and analysis put forth in the
<a href="http://freehaven.net/anonbib/topic.html">anonymity literature</a> (largely
<a href="http://citeseer.ist.psu.edu/454354.html">Traffic Analysis: Protocols, Attacks, Design
Issues and Open Problems</a>), the following briefly describes a wide variety
of attacks as well as many of I2Ps defenses. We update
this list to include new attacks as they are identified.
</p><p>
Included are some attacks that may be unique to I2P.
We do not have good answers for all these attacks, however
we continue to do research and improve our defenses.
</p><p>
In addition, many of these attacks are significantly easier than
they should be, due to the modest size of the current network.
While we are aware of some limitations that need to be addressed,
I2P is designed to support hundreds of thousands, or millions, of
participants.
As we continue to spread the word and grow the network,
these attacks will become much harder.
</p><p>
The
<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>
<h3 id="index">Index</h3>
<ul>
<li><a href="#bruteforce">Brute force attacks</a></li>
<li><a href="#timing">Timing attacks</a></li>
<li><a href="#intersection">Intersection attacks</a></li>
<li><a href="#dos">Denial of service attacks</a></li>
<li><a href="#tagging">Tagging attacks</a></li>
<li><a href="#partitioning">Partitioning attacks</a></li>
<li><a href="#predecessor">Predecessor attacks</a></li>
<li><a href="#harvesting">Harvesting attacks</a></li>
<li><a href="#traffic">Identification Through Traffic Analysis</a></li>
<li><a href="#sybil">Sybil attacks</a></li>
<li><a href="#buddy">Buddy Exhaustion attacks</a></li>
<li><a href="#crypto">Cryptographic attacks</a></li>
<li><a href="#floodfill">Floodfill attacks</a></li>
<li><a href="#netdb">Other Network Database attacks</a></li>
<li><a href="#central">Attacks on centralized resources</a></li>
<li><a href="#dev">Development attacks</a></li>
<li><a href="#impl">Implementation attacks</a></li>
<li><a href="#blocklist">Other Defenses</a></li>
</ul>
<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
which message follows which path. Mounting this attack against I2P should be
nontrivial, as all peers in the network are frequently sending messages (both
end to end and network maintenance messages), plus an end to end message changes
size and data along its path. In addition, the external adversary does not have
access to the messages either, as inter-router communication is both encrypted
and streamed (making two 1024 byte messages indistinguishable from one 2048 byte
message).</p>
<p>However, a powerful attacker can use brute force to detect trends - if they
can send 5GB to an I2P destination and monitor everyone's network connection,
they can eliminate all peers who did not receive 5GB of data. Techniques to
defeat this attack exist, but may be prohibitively expensive (see:
<a href="http://citeseer.ist.psu.edu/freedman02tarzan.html">Tarzan</a>'s mimics
or constant rate traffic). Most users are not concerned with this attack, as
the cost of mounting it are extreme (and often require illegal activity).
However, the attack is still possible, for example by an observer at
a large ISP or an Internet exchange point.
Those who want to defend against it
would want to take appropriate countermeasures, such as
setting low bandwidth limits, and using unpublished or encrypted leasesets for eepsites.
Other countermeasures, such as nontrivial delays and restricted routes, are
not currently implemented.
</p><p>
As a partial defense against a single router or group of routers trying to route all the network's traffic,
routers contain limits as to how many tunnels can be routed through a single peer.
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="{{ site_url('docs/how/peerselection') }}">peer selection page</a>.
</p>
<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
recognizable patterns within the frequency of their messages - for instance, an
HTTP request will be a small message with a large sequence of reply messages
containing the HTTP response. Using this data as well as a broad view of the
network topology, an attacker may be able to disqualify some links as being too
slow to have passed the message along.</p>
<p>This sort of attack is powerful, but its applicability to I2P is non obvious,
as the variation on message delays due to queuing, message processing, and
throttling will often meet or exceed the time of passing a message along a
single link - even when the attacker knows that a reply will be sent as soon as
the message is received. There are some scenarios which will expose fairly
automatic replies though - the streaming library does (with the SYN+ACK) as does the
message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).</p>
<p>Without protocol scrubbing or higher latency, global active adversaries can
gain substantial information. As such, people concerned with these attacks could
increase the latency (using <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>,
but these are unimplemented in I2P.
</p>
<p>References:
<a href="http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf">Low-Resource Routing Attacks Against Anonymous Systems</a>
</p>
<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
the network. Over time, as node churn occurs the attacker will gain
significant information about the target by simply intersecting the sets of
peers that are online when a message successfully goes through. The cost of
this attack is significant as the network grows, but may be feasible in some
scenarios.</p>
<p>
In summary, if an attacker is at both ends of your tunnel at the same time,
he may be successful.
I2P does not have a full defense to this for low latency communication.
This is an inherent weakness of low-latency onion routing.
Tor provides a <a href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatattacksremainagainstonionrouting">similar disclaimer</a>.
</p><p>
Partial defenses implemented in I2P:
<ul><li>
<a href="tunnel-alt.html#ordering">strict ordering</a> of peers
</li><li>
<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>
Prevention of peers from the same /16 IP range from being members of a single tunnel
</li><li>
For eepsites or other hosted services, we support
simultaneous hosting on multiple routers, or
<a href="{{ site_url('docs/how/threatmodel') }}#intersection">multihoming</a>
</li></ul>
Even in total, these defenses are not a complete solution.
Also, we have made some design choices that may significantly increase our vulnerability:
<ul><li>
We do not use low-bandwidth "guard nodes"
</li><li>
We use tunnel pools comprised of several tunnels, and traffic can shift from tunnel to tunnel.
</li><li>
Tunnels are not long-lived; new tunnels are built every 10 minutes.
</li><li>
Tunnel lengths are configurable.
While 3-hop tunnels are recommended for full protection, several applications and
services use 2-hop tunnels by default.
</li></ul>
</p><p>
In the future, it could
for peers who can afford significant delays (per <a href="todo#stop">nontrivial
delays</a> and <a href="todo#batching">batching strategies</a>). In addition,
this is only relevant 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>
<p>Reference:
<a href="http://blog.torproject.org/blog/one-cell-enough">One Cell Enough</a>
</p>
<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>
<li><b>Greedy user attack:</b> This is simply
people trying to consume significantly more resources than they are
willing to contribute. The defense against this is:<ul>
<li>Set defaults so that most users provide resources to the network.
In I2P, users route traffic by default. In sharp distinction to
<a href="https://torproject.org/">other networks</a>,
over 95% of I2P users relay traffic for others.
</li>
<li>Provide easy configuration options so that users may increase their
contribution (share percentage) to the network. Display easy-to-understand
metrics such as "share ratio" so that users may see what they are contributing.
</li><lil>
Maintain a strong community with blogs, forums, IRC, and other means of communication.
</li></ul>
<li><b>Starvation attack:</b> A hostile user may attempt to harm the network by
creating a significant number of peers in the network who are not identified as
being under control of the same entity (as with Sybil). These nodes then
decide not to provide any resources to the network, causing existing peers
to search through a larger network database or request more tunnels than
should be necessary.
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="{{ 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
ability to recognize and avoid troublesome peers; however there are still
significant efforts required in this area.
</li>
<li><b>Flooding attack:</b> A hostile user may attempt to flood the network,
a peer, a destination, or a tunnel. Network and peer flooding is possible,
and I2P does nothing to prevent standard IP layer flooding. The flooding of
a destination with messages by sending a large number to the target's various
inbound tunnel gateways is possible, but the destination will know this both
by the contents of the message and because the tunnel's tests will fail. The
same goes for flooding just a single tunnel. I2P has no defenses for a network
flooding attack. For a destination and tunnel flooding attack, the target
identifies which tunnels are unresponsive and builds new ones. New code could
also be written to add even more tunnels if the client wishes to handle the
larger load. If, on the other hand, the load is more than the client can
deal with, they can instruct the tunnels to throttle the number of messages or
bytes they should pass on (once the <a href="todo#batching">advanced tunnel
operation</a> is implemented).</li>
<li><b>CPU load attack:</b> There are currently some methods for people to
remotely request that a peer perform some cryptographically expensive
operation, and a hostile attacker could use these to flood that peer with
a large number of them in an attempt to overload the CPU. Both using good
engineering practices and potentially requiring nontrivial certificates
(e.g. HashCash) to be attached to these expensive requests should mitigate
the issue, though there may be room for an attacker to exploit various
bugs in the implementation.</li>
<li id="ffdos"><b>Floodfill DOS attack:</b> A hostile user may attempt to harm the network by
becoming a floodfill router. The current defenses against unreliable,
intermittent, or malicious floodfill routers are poor.
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="{{ site_url('docs/how/peerselection') }}">peer profiling</a> are implemented,
however there is much more to do.
For more information see the
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
</li>
</ul>
<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
tunnel gateway as well as a participant further along in that tunnel, with
collusion they can identify the fact that they are in the same tunnel (and
prior to adding <a href="todo#tunnelId">unique hop ids</a> and other updates,
colluding peers within the same tunnel can recognize that fact without any
effort). An attacker in an outbound tunnel and any part of an inbound tunnel cannot
collude however, as the tunnel encryption pads and modifies the data separately
for the inbound and outbound tunnels. External attackers cannot do anything,
as the links are encrypted and messages signed.</p>
<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
powerful adversary, since the size of the network plays a key role in determining
your anonymity. Technical partitioning by cutting links between peers to create
fragmented networks is addressed by I2P's built in network database, which
maintains statistics about various peers so as to allow any existing connections
to other fragmented sections to be exploited so as to heal the network. However,
if the attacker does disconnect all links to uncontrolled peers, essentially
isolating the target, no amount of network database healing will fix it. At
that point, the only thing the router can hope to do is notice that a significant
number of previously reliable peers have become unavailable and alert the client
that it is temporarily disconnected (this detection code is not implemented at
the moment).</p>
<p>Partitioning the network analytically by looking for differences in how routers
and destinations behave and grouping them accordingly is also a very powerful
attack. For instance, an attacker <a href="#harvesting">harvesting</a> the network
database will know when a particular destination has 5 inbound tunnels in their
LeaseSet while others have only 2 or 3, allowing the adversary to potentially
partition clients by the number of tunnels selected. Another partition is
possible when dealing with the <a href="todo#stop">nontrivial delays</a> and
<a href="todo#batching">batching strategies</a>, as the tunnel gateways and the
particular hops with non-zero delays will likely stand out. However, this data
is only exposed to those specific hops, so to partition effectively on that
matter, the attacker would need to control a significant portion of the network
(and still that would only be a probabilistic partition, as they wouldn't know
which other tunnels or messages have those delays).
</p><p>
Also discussed on the
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a> (bootstrap attack).
</p>
<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
keeping track of the previous or next hop (for outbound or inbound tunnels,
respectively). Over time, using a perfectly random sample of peers and random
ordering, an attacker would be able to see which peer shows up as 'closer'
statistically more than the rest, and that peer would in turn be where the
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="{{ 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>
(not enabled by default)
even 0 hop tunnels can provide plausible deniability as the occasional
variation of the gateway will look like normal tunnels. Fourth, with
<a href="todo#fullRestrictedRoutes">restricted routes</a> (unimplemented), only the peer with
a restricted connection to the target will ever contact the target, while
attackers will merely run into that gateway.
</p><p>
The current
<a href="tunnel-alt-creation.html">tunnel build method</a>
was specifically designed to combat the predecessor attack.
See also <a href="#intersection">the intersection attack</a>.
</p>
<p>References:
<a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf</a>
which is an update to the 2004 predecessor attack paper
<a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf</a>.
</p>
<h3 id="harvesting">Harvesting attacks</h3>
<p>
"Harvesting" means compiling a list of users running I2P.
It can be used for legal attacks and to help
other attacks by simply running a peer, seeing who it connects to, and
harvesting whatever references to other peers it can find.
</p><p>
I2P itself is not designed with effective defenses against
this attack, since there is the distributed network database
containing just this information.
The following factors make the attack somewhat harder in practice:
<ul><li>
Network growth will make it more difficult to obtain a given proportion of the network
</li><li>
Floodfill routers implement query limits as DOS protection
</li><li>
"Hidden mode", which prevents a router from publishing its information to the netDb,
(but also prevents it from relaying data) is not widely used now but could be.
</li></ul>
In future implementations,
<a href="todo#nat">basic</a> and
<a href="todo#fullRestrictedRoutes">comprehensive</a> restricted routes,
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><p>
In the future, routers could use GeoIP to identify if they are in a particular
country where identification as an I2P node would be risky.
In that case, the router could automatically enable hidden mode, or
enact other restricted route methods.
</p>
<h3 id="traffic">Identification Through Traffic Analysis</h3>
<p>
By inspecting the traffic into and out of a router, a malicious ISP
or state-level firewall could identify that a computer is running I2P.
As discussed <a href="#harvesting">above</a>, I2P is not specifically designed
to hide that a computer is running I2P. However, several design decisions made
in the design of the
<a href="transport.html">transport layer and protocols</a>
make it somewhat difficult to identify I2P traffic:
<ul><li>
Random port selection
</li><li>
Point-to-Point Encryption of all traffic
</li><li>
DH key exchange with no protocol bytes or other unencrypted constant fields
</li><li>
Simultaneous use of both
<a href="ntcp.html">TCP</a> and
<a href="udp.html">UDP</a> transports.
UDP may be much harder for some Deep Packet Inspection (DPI) equipment to track.
</li></ul>
In the near future, we plan to directly address traffic analysis issues by further obfuscation of I2P transport protocols, possibly including:
<ul><li>
Padding at the transport layer to random lengths, especially during the connection handshake
</li><li>
Study of packet size distribution signatures, and additional padding as necessary
</li><li>
Development of additional transport methods that mimic SSL or other common protocols
</li><li>
Review of padding strategies at higher layers to see how they affect packet sizes at the transport layer
</li><li>
Review of methods implemented by various state-level firewalls to block Tor
</li><li>
Working directly with DPI and obfuscation experts
</li></ul>
</p><p>
Reference:
<a href="http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf">Breaking and Improving Protocol Obfuscation</a>
</p>
<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
mounting other attacks. For instance, if an attacker is in a network where peers
are selected randomly and they want an 80% chance to be one of those peers, they
simply create five times the number of nodes that are in the network and roll
the dice. When identity is free, Sybil can be a very potent technique for a
powerful adversary. The primary technique to address this is simply to make
identity 'non free' - <a href="http://www.pdos.lcs.mit.edu/tarzan/">Tarzan</a>
(among others) uses the fact that IP addresses are limited, while
IIP used
<a href="http://www.hashcash.org/">HashCash</a> to 'charge' for creating a new
identity. We currently have not implemented any particular technique to address
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><p>
Requiring HashCash Certificates in various places has two major problems:
<ul><li>
Maintaining backward compatibility
</li><li>
The classic HashCash problem -
selecting HashCash values that are meaningful proofs of work on high-end machines,
while still being feasible on low-end machines such as mobile devices.
</li></ul>
</p><p>
Various limitations on the number of routers in a given IP range restrict
the vulnerability to attackers that don't have the ability to put machines
in several IP blocks.
However, this is not a meaningful defense against a powerful adversary.
</p><p>
See the
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>
for more Sybil discussion.
</p>
<h3 id="buddy">Buddy Exhaustion attacks</h3>
<p>
(Reference:
<a href="https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf">In Search of an Anonymouns and Secure Lookup</a> Section 5.2)
</p>
<p>
By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure
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="{{ 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.
The malicous routers could also maintain connections to the target router and provide
excellent forwarding bandwidth for traffic over those connections, in an attempt
to manipulate the profiles managed by the target and appear attractive.
Further research and defenses may be necessary.
</p>
<h3 id="crypto">Cryptographic attacks</h3>
<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="{{ 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,
and defense against man-in-the-middle attacks.
The key sizes chosen in 2003 were quite conservative at the time, and are still longer than
those used in <a href="https://torproject.org/">other anonymity networks</a>.
We don't think the current key lengths are our biggest weakness,
especially for traditional, non-state-level adversaries;
bugs and the small size of the network are much more worrisome.
Of course, all cryptographic algorithms eventually become obsolete due to
the advent of faster processors, cryptographic research, and advancements in
methods such as rainbow tables, clusters of video game hardware, etc.
Unfortunately, I2P was not designed with easy mechanisms to lengthen keys or change
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="{{ 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.
</p><p>
In the future,
several I2P protocols and data structures
support securely padding messages to arbitrary sizes, so messages could be made constant
size or garlic messages could be modified randomly so that some cloves appear to contain
more subcloves than they actually do. At the moment, however, garlic, tunnel, and
end to end messages include simple random padding.</p>
<h3 id="floodfill">Floodfill Anonymity attacks</h3>
<p>
In addition to the floodfill DOS attacks described
<a href="#ffdos">above</a>, floodfill routers are uniquely positioned
to learn about network participants, due to their role
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="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
The specific mechanisms by which routers communicate with floodfills have been
<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>
<h3 id="netdb">Other Network Database attacks</h3>
<p>
A hostile user may attempt to harm the network by
creating one or more floodfill routers and crafting them to offer
bad, slow, or no responses.
Several scenarios are discussed on the
<a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
</p>
<h3 id="central">Central Resource Attacks</h3>
<p>
There are a few centralized or limited resources (some inside I2P, some not)
that could be attacked or used as a vector for attacks.
The absence of jrandom starting November 2007, followed by the loss of the i2p.net hosting service in January 2008,
highlighted numerous centralized resources in the development and operation of the I2P network,
most of which are now distributed.
Attacks on externally-reachable resources mainly affect the ability of new users to find us,
not the operation of the network itself.
<ul>
<li>The <a href="/">website</a> is mirrored and uses DNS round-robin for external public access.
<li>Routers now support <a href="faq.html#reseed">multiple external reseed locations</a>,
however more reseed hosts may be needed, and the handling of unreliable or malicious
reseed hosts may need improvement.
<li>Routers now support multiple update file locations.
A malicious update host could feed a huge file, need to limit the size.
<li>Routers now support multiple default trusted update signers.
<li>Routers now better handle <a href="#ffdos">multiple unreliable floodfill peers</a>.
Malicious floodfills <a href="#ffdos">needs</a> <a href="#floodfill">more</a> study.
<li>The code is now stored in a <a href="monotone.html">distributed source control system</a>.
<li>Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host.
A malicious news host could feed a huge file, need to limit the size.
<li><a href="naming.html">Naming system services</a>, including addressbook subscription providers, add-host services,
and jump services, could be malicious. Substantial protections for subscriptions were implemented
in release 0.6.1.31, with additional enhancements in subsequent releases.
However, all naming services require some measure of trust, see
<a href="naming.html">the naming page</a> for details.
<li>We remain reliant on the DNS service for i2p2.de, losing this would cause substantial
disruption in our ability to attract new users,
and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did.
</ul>
<h3 id="dev">Development attacks</h3>
<p>
These attacks aren't directly on the network, but instead go after its development team
by either introducing legal hurdles on anyone contributing to the development
of the software, or by using whatever means are available to get the developers to
subvert the software. Traditional technical measures cannot defeat these attacks, and
if someone threatened the life or livelihood of a developer (or even just issuing a
court order along with a gag order, under threat of prison), we would have a big problem.
</p>
<p>
However, two techniques help defend against these attacks:
<ul>
<li> All components of the network must be open source to enable inspection, verification,
modification, and improvement. If a developer is compromised, once it is noticed
the community should demand explanation and cease to accept that developer's work.
All checkins to our <a href="monotone.html">distributed source control system</a>
are cryptographically signed, and the release packagers use a trust-list system
to restrict modifications to those previously approved.
</li>
<li> Development over the network itself, allowing developers to stay anonymous but still
secure the development process. All I2P development can occur through I2P - using
a <a href="monotone.html">distributed source control system</a>,
a distributed source control system, IRC chat,
public web servers,
discussion forums (forum.i2p), and the software distribution sites,
all available within I2P.</li>
</ul>
We also maintain relationships with various organizations that offer legal advice,
should any defense be necessary.
</p>
<h3 id="impl">Implementation attacks (bugs)</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
attack the anonymity or security of the communication running over I2P in unexpected
ways. To help withstand attacks against the design or protocols in use, we publish
all designs and documentation and solicit review and criticism with
the hope that many eyes will improve the system.
We do not believe in
<a href="http://www.haystacknetwork.com/">security through obscurity</a>.
</p><p>
In addition, the code is being
treated the same way, with little aversion towards reworking or throwing out
something that isn't meeting the needs of the software system (including ease of
modification). Documentation for the design and implementation of the network and
the software components are an essential part of security, as without them it is
unlikely that developers would be willing to spend the time to learn the software
enough to identify shortcomings and bugs.
</p><p>
Our software is likely, in particular, to contain bugs related to denial of service
through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues in the router console,
and other vulnerabilities to non-standard inputs via the various protocols.
</p><p>
I2P is still a small network with a small development community and almost no
interest from academic or research groups.
Therefore we lack the analysis that
<a href="https://torproject.org/">other anonymity networks</a>
may have received. We continue to recruit people to
<a href="getinvolved.html">get involved</a> and help.
</p>
<h2>Other Defenses</h2>
<h3 id="blocklist">Blocklists</h3>
<p>
To some extent, I2P could be enhanced to avoid peers operating at IP addresses
listed in a blocklist. Several blocklists are commonly available in standard formats,
listing anti-P2P organizations, potential state-level adversaries, and others.
<p>
To the extent that active peers actually do show up in the actual blocklist,
blocking by only a subset of peers would tend to segment the network,
exacerbate reachability problems, and decrease overall reliability.
Therefore we would want to agree on a particular blocklist and
enable it by default.
<p>
Blocklists are only a part (perhaps a small part) of an array of defenses
against maliciousness.
In large part the profiling system does a good job of measuring
router behavior so that we don't need to trust anything in netDb.
However there is more that can be done. For each of the areas in the
list above there are improvements we can make in detecting badness.
<p>
If a blocklist is hosted at a central location with automatic updates
the network is vulnerable to a
<a href="#central">central resource attack</a>.
Automatic subscription to a list gives the list provider the power to shut
the i2p network down. Completely.
<p>
Currently, a default blocklist is distributed with our software,
listing only the IPs of past DOS sources.
There
is no automatic update mechanism.
Should a particular IP range implement serious attacks on the I2P network,
we would have to ask people to update their blocklist manually through
out-of-band mechanisms such as forums, blogs, etc.
</p>
{% endblock %}

255
i2p2www/pages/site/docs/how/tunnelrouting.html Normal file
View File

@@ -0,0 +1,255 @@
{% extends "global/layout.html" %}
{% block title %}Tunnel Overview{% endblock %}
{% block content %}
<p>
Updated July 2011 for release 0.8.7
</p>
<h2>Tunnel Overview</h2>
<p>
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="{{ 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
(where the tunnel creator shoves messages away from them). When Alice
wants to send a message to Bob, she will (typically) send it out one of
her existing outbound tunnels with instructions for that tunnel's endpoint
to forward it to the gateway router for one of Bob's current inbound
tunnels, which in turn passes it to Bob.</p>
<p style="text-align:center;">
<img src="{{ url_for('static', filename='images/tunnelSending.png') }}" alt="Tunnel" />
<pre>
A: Outbound Gateway (Alice)
B: Outbound Participant
C: Outbound Endpoint
D: Inbound Gateway
E: Inbound Participant
F: Inbound Endpoint (Bob)
</pre>
</p>
<h2>Tunnel vocabulary</h2>
<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="{{ 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
endpoint (e.g. both B and E above)</li>
<li><b>n-Hop tunnel</b> - a tunnel with a specific number of inter-router jumps, e.g.:
<ul>
<li><b>0-hop tunnel</b> - a tunnel where the gateway is also the endpoint</li>
<li><b>1-hop tunnel</b> - a tunnel where the gateway talks directly to the
endpoint</li>
<li><b>2-(or more)-hop tunnel</b> - a tunnel where there is at least one intermediate
tunnel participant. (the above diagram includes two 2-hop tunnels - one
outbound from Alice, one inbound to Bob)</li>
</ul>
</li>
<li class="gap"><b>Tunnel ID</b> - A <a href="common_structures_spec.html#type_TunnelId">4 byte integer</a>
different for each hop in a tunnel, and unique among all tunnels on a router.
Chosen randomly by the tunnel creator.</li>
</ul>
<h2>Tunnel Build Information</h2>
<p>Routers performing the three roles (gateway, participant, endpoint) are given
different pieces of data in the initial
<a href="tunnel-alt-creation.html">Tunnel Build Message</a>
to accomplish their tasks:</p>
<ul>
<li class="gap"><b>The tunnel gateway gets:</b>
<ul>
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
messages and instructions to the next hop</li>
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
the IV to the next hop</li>
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
the reply to the tunnel build request</li>
<li><b>reply IV</b> - the IV for encrypting
the reply to the tunnel build request</li>
<li><b>tunnel id</b> - 4 byte integer (inbound gateways only)
</li>
<li><b>next hop</b> - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint)</li>
<li><b>next tunnel id</b> - The tunnel ID on the next hop</li>
</ul>
</li>
<li class="gap"><b>All intermediate tunnel participants get:</b>
<ul>
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
messages and instructions to the next hop</li>
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
the IV to the next hop</li>
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
the reply to the tunnel build request</li>
<li><b>reply IV</b> - the IV for encrypting
the reply to the tunnel build request</li>
<li><b>tunnel id</b> - 4 byte integer
</li>
<li><b>next hop</b> - what router is the next one in the path</li>
<li><b>next tunnel id</b> - The tunnel ID on the next hop</li>
</ul>
</li>
<li class="gap"> <b>The tunnel endpoint gets:</b>
<ul>
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
messages and instructions to the the endpoint (itself)</li>
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
the IV to the endpoint (itself)</li>
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
the reply to the tunnel build request (outbound endpoints only)</li>
<li><b>reply IV</b> - the IV for encrypting
the reply to the tunnel build request (outbound endpoints only)</li>
<li><b>tunnel id</b> - 4 byte integer (outbound endpoints only)
</li>
<li><b>reply router</b> - the inbound gateway of the tunnel to send the reply through (outbound endpoints only)</li>
<li><b>reply tunnel id</b> - The tunnel ID of the reply router (outbound endpoints only)</li>
</ul>
</li>
</ul>
<p>
Details are in the
<a href="tunnel-alt-creation.html">tunnel creation specification</a>.
</p>
<h2>Tunnel pooling</h2>
<p>
Several tunnels for a particular purpose may be grouped into a "tunnel pool",
as described in the
<a href="tunnel-alt.html#tunnel.pooling">tunnel specification</a>.
This provides redundancy and additional bandwidth.
The pools used by the router itself are called "exploratory tunnels".
The pools used by applications are called "client tunnels".
</p>
<h2 id="length">Tunnel length</h2>
<p>As mentioned above, each client requests that their router provide tunnels to
include at least a certain number of hops.
The decision as to how many routers
to have in one's outbound and inbound tunnels has an important effect upon the
latency, throughput, reliability, and anonymity provided by I2P - the more peers
that messages have to go through, the longer it takes to get there and the more
likely that one of those routers will fail prematurely. The less routers in a
tunnel, the easier it is for an adversary to mount traffic analysis attacks and
pierce someone's anonymity.
Tunnel lengths are specified by clients via
<a href="i2cp.html#options">I2CP options</a>.
The maximum number of hops in a tunnel is 7.
</p>
<h3>0-hop tunnels</h3>
<p>With no remote routers in a tunnel, the user has very basic plausible
deniability (since no one knows for sure that the peer that sent them the
message wasn't simply just forwarding it on as part of the tunnel). However, it
would be fairly easy to mount a statistical analysis attack and notice that
messages targeting a specific destination are always sent through a single
gateway. Statistical analysis against outbound 0-hop tunnels are more complex,
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="{{ 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>
<h3>2-hop tunnels</h3>
<p>With two or more remote routers in a tunnel, the costs of mounting the traffic
analysis attack increases, since many remote routers would have to be compromised
to mount it.</p>
<h3>3-hop (or more) tunnels</h3>
To reduce the susceptibility to <a href="http://blog.torproject.org/blog/one-cell-enough">some attacks</a>,
3 or more hops are recommended for the highest level of protection.
<a href="http://blog.torproject.org/blog/one-cell-enough">recent studies</a>
also conclude that more than 3 hops does not provide additional protection.
<h3>Tunnel default lengths</h3>
<p>The router uses 2-hop tunnels by default for its exploratory tunnels.
Client tunnel defaults are set by the application, using
<a href="i2cp.html#options">I2CP options</a>.
Most applications use 2 or 3 hops as their default.
</p>
<h2 id="testing">Tunnel testing</h2>
<p>All tunnels are periodically tested by their creator by sending a
DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel
(testing both tunnels at once). If either fails a number of consecutive tests, it is marked as no longer
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="{{ 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="{{ 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
or other non-free certificates when necessary).
That router forwards the message to the next hop in the tunnel.
Details are in the
<a href="tunnel-alt-creation.html">tunnel creation specification</a>.
</p>
<h2>Tunnel encryption</h2>
<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>.
The IV of each hop is encrypted with a separate key as explained there.
</p>
<h2>Future Work</h2>
<ul><li>
Other tunnel test techniques could be used, such as
garlic wrapping a number of tests into cloves, testing individual tunnel
participants separately,
etc.
</li><li>
Move to 3-hop exploratory tunnels defaults.
</li><li>
In a distant future release,
options specifying the pooling, mixing, and chaff generation settings may be implemented.
</li><li>
In a distant future release,
limits on the quantity and size of messages allowed during the
tunnel's lifetime may be implemented (e.g. no more than 300 messages or
1MB per minute).
</li></ul>
<h2>See Also</h2>
<ul>
<li>
<a href="tunnel-alt.html">tunnel specification</a>
</li><li>
<a href="tunnel-alt-creation.html">tunnel creation specification</a>
</li><li>
<a href="unidirectional-tunnels.html">Unidirectional Tunnels</a>
</li><li>
<a href="tunnel_message_spec.html">tunnel message specification</a>
</li><li>
<a href="{{ site_url('docs/how/garlicrouting') }}">garlic routing</a>
</li><li>
<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
</li><li>
<a href="i2cp.html#options">I2CP options</a>
</li>
</ul>
{% endblock %}

888
i2p2www/pages/site/docs/techintro.html Normal file
View File

@@ -0,0 +1,888 @@
{% extends "global/layout.html" %}
{% block title %}Introducing I2P{% endblock %}
{% block content %}
<h1 class="title">I2P: <span style="font-size:medium;">A scalable framework for anonymous communication</span></h1>
<div id="toc">
<h2>Table of Contents</h2>
<ul>
<li><a href="#intro">Introduction</a></li>
<li>
<a href="#op">I2P Operation</a>
<ul>
<li><a href="#op.overview">Overview</a></li>
<li><a href="#op.tunnels">Tunnels</a></li>
<li><a href="#op.netdb">Network Database</a></li>
<li><a href="#op.transport">Transport protocols</a></li>
<li><a href="#op.crypto">Cryptography</a></li>
</ul>
</li>
</ul>
</div>
<br/>
<h1 id="intro">Introduction</h1>
<p>
I2P is a scalable, self organizing, resilient packet switched anonymous
network layer, upon which any number of different anonymity or security conscious
applications can operate. Each of these applications may make their own anonymity,
latency, and throughput tradeoffs without worrying about the proper implementation
of a free route mixnet, allowing them to blend their activity with the larger
anonymity set of users already running on top of I2P.
</p>
<p>
Applications available already provide the full range of typical Internet activities -
<b>anonymous</b> web browsing, web hosting, chat, file sharing, e-mail,
blogging and content syndication, newsgroups, as well as several other applications under development.
<ul>
<li>Web browsing: using any existing browser that supports using a proxy.</li>
<li>Chat: IRC, Jabber, <a href="#app.i2pmessenger">I2P-Messenger</a>.</li>
<li>File sharing: <a href="#app.i2psnark">I2PSnark</a>, <a href="#app.robert">Robert</a>, <a href="#app.imule">iMule</a>,
<a href="#app.i2phex">I2Phex</a>, <a href="#app.pybit">PyBit</a>, <a href="#app.i2pbt">I2P-bt</a>
and others.
</li>
<li>E-mail: <a href="#app.i2pmail">susimail</a> and <a href="#app.i2pbote">I2P-Bote</a>.</li>
<li>Blog: using e.g. the pebble plugin or the distributed blogging software <a href="#app.syndie">Syndie</a>.</li>
<li>Distributed Data Store: Save your data redundantly in the Tahoe-LAFS cloud over I2P.</li>
<li>Newsgroups: using any newsgroup reader that supports using a proxy.</li>
</ul>
<p>
Unlike web sites hosted within content distribution networks like <a href="#similar.freenet">Freenet</a>
or <a href="http://www.ovmj.org/GNUnet/">GNUnet</a>, the services hosted on
I2P are fully interactive - there are traditional web-style search engines,
bulletin boards, blogs you can comment on, database driven sites, and bridges
to query static systems like Freenet without needing to install it locally.
</p>
<p>
With all of these anonymity enabled applications, I2P takes on the role
of the message oriented middleware - applications say that they want to send
some data to a cryptographic identifier (a "destination") and I2P takes care
of making sure it gets there securely and anonymously. I2P also bundles a
simple <a href="#app.streaming">streaming</a> library to allow I2P's anonymous
best-effort messages to transfer as reliable, in-order streams, transparently
offering a TCP based congestion control algorithm tuned for the high bandwidth
delay product of the network. While there have been several simple SOCKS proxies
available to tie existing applications into the network, their value has been
limited as nearly every application routinely exposes what, in an anonymous
context, is sensitive information. The only safe way to go is to fully audit
an application to ensure proper operation and to assist in that we provide
a series of APIs in various languages which can be used to make the most out
of the network.
</p>
<p>
I2P is not a research project - academic, commercial, or governmental, but
is instead an engineering effort aimed at doing whatever is necessary to provide
a sufficient level of anonymity to those who need it. It has been in active
development since early 2003 with one full time developer and a dedicated
group of part time contributors from all over the world. All of the work done
on I2P is open source and freely available on the <a href="index.html">website</a>,
with the majority of the code released outright into the public domain, though
making use of a few cryptographic routines under BSD-style licenses. The people
working on I2P do not control what people release client applications under,
and there are several GPL'ed applications available (<a href="#app.i2ptunnel">I2PTunnel</a>,
<a href="#app.i2pmail">susimail</a>, <a href="#app.i2psnark">I2PSnark</a>, <a href="#app.i2pbote">I2P-Bote</a>,
<a href="#app.i2phex">I2Phex</a> and others.).
<a href="http://www.i2p.net/halloffame">Funding</a> for I2P comes entirely from donations,
and does not receive any tax breaks in any jurisdiction at this time,
as many of the developers are themselves anonymous.
</p>
<h1 id="op">Operation</h1>
<h2 id="op.overview">Overview</h2>
<p>
To understand I2P's operation, it is essential to understand a few key concepts.
First, I2P makes a strict separation between the software participating in
the network (a "router") and the anonymous endpoints ("destinations") associated
with individual applications. The fact that someone is running I2P is not
usually a secret. What is hidden is information on what the user is doing,
if anything at all, as well as what router a particular destination is connected
to. End users will typically have several local destinations on their router
- for instance, one proxying in to IRC servers, another supporting the user's
anonymous webserver ("eepsite"), another for an I2Phex instance, another for
torrents, etc.
</p>
<p>
Another critical concept to understand is the "tunnel".
A tunnel is a directed path through an explicitly selected list of routers.
Layered encryption is used, so each of the routers can only decrypt a single layer.
The decrypted information contains the IP of the next router, along with
the encrypted information to be forwarded.
Each tunnel has a starting point (the first router, also known as "gateway")
and an end point. Messages can be sent only in one way. To send messages back,
another tunnel is required.
</p>
<div class="box" style="text-align:center;">
<img src="{{ url_for('static', filename='images/tunnels.png') }}" alt="Inbound and outbound tunnel schematic" title="Inbound and outbound tunnel schematic" />
<br /><br />
Figure 1: Two types of tunnels exist: inbound and outbound.
</div>
<br/>
<p>
Two types of tunnels exist:
<b>"outbound" tunnels</b> send messages away from the tunnel creator,
while <b>"inbound" tunnels</b> bring messages to the tunnel creator.
Combining these two tunnels allows users to send messages to each other.
The sender ("Alice" in the above image) sets up an outbound tunnel,
while the receiver ("Bob" in the above image) creates an inbound tunnel.
The gateway of an inbound tunnel can receive messages from any other user
and will send them on until the endpoint ("Bob").
The endpoint of the outbound tunnel will need to send the message
on to the gateway of the inbound tunnel.
To do this, the sender ("Alice") adds instructions to her encrypted message.
Once the endpoint of the outbound tunnel decrypts the message,
it will have instructions to forward the message to the correct
inbound gateway (the gateway to "Bob").
</p>
<p>
A third critical concept to understand is I2P's <b>"network database"</b> (or "netDb")
- a pair of algorithms used to share network metadata. The two types of metadata
carried are <b>"routerInfo"</b> and <b>"leaseSets"</b> - the routerInfo gives routers the
data necessary for contacting a particular router (their public keys, transport
addresses, etc), while the leaseSet gives routers the information necessary
for contacting a particular destination. A leaseSet contains a number of "leases".
Each of this leases specifies a tunnel gateway, which allows reaching a specific destination.
The full information contained in a lease:
<ul>
<li>Inbound gateway for a tunnel that allows reaching a specific destination.</li>
<li>Time when a tunnel expires.</li>
<li>Pair of public keys to be able to encrypt messages (to send through the tunnel and reach the destination).</li>
</ul>
Routers themselves send their routerInfo to the netDb directly, while leaseSets are sent through outbound tunnels
(leaseSets need to be sent anonymously, to avoid correlating a router with his leaseSets).
</p>
<p>
We can combine the above concepts to build successful connections in the network.
</p>
<p>
To build up her own inbound and outbound tunnels, Alice does a lookup in the netDb to collect routerInfo.
This way, she gathers lists of peers she can use as hops in her tunnels.
She can then send a build message to the first hop, requesting the construction of a tunnel and asking
that router to send the construction message onward, until the tunnel has been constructed.
</p>
<div class="box" style="text-align:center;">
<img src="{{ url_for('static', filename='images/netdb_get_routerinfo_1.png') }}" alt="Request information on other routers" title="Request information on other routers" />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<img src="{{ url_for('static', filename='images/netdb_get_routerinfo_2.png') }}" alt="Build tunnel using router information" title="Build tunnel using router information" />
<br /><br />
Figure 2: Router information is used to build tunnels.
</div>
<br/>
<p>
When Alice wants to send a message to Bob, she first does a lookup in the
netDb to find Bob's leaseSet, giving her his current inbound tunnel gateways.
She then picks one of her outbound tunnels and sends the message down it with
instructions for the outbound tunnel's endpoint to forward the message on
to one of Bob's inbound tunnel gateways. When the outbound tunnel endpoint
receives those instructions, it forwards the message as requested, and when
Bob's inbound tunnel gateway receives it, it is forwarded down the tunnel
to Bob's router. If Alice wants Bob to be able to reply to the message, she
needs to transmit her own destination explicitly as part of the message itself.
This can be done by introducing a higher-level layer, which is done in the
<a href="#app.streaming">streaming</a> library.
Alice may also cut down on the response time by bundling her most
recent leaseSet with the message so that Bob doesn't need to do a netDb lookup
for it when he wants to reply, but this is optional.
</p>
<div class="box" style="text-align:center;">
<img src="{{ url_for('static', filename='images/netdb_get_leaseset.png') }}" alt="Connect tunnels using leaseSets" title="Connect tunnels using leaseSets" />
<br /><br />
Figure 3: Leasesets are used to connect outbound and inbound tunnels.
</div>
<br/>
<p>
While the tunnels themselves have layered encryption to prevent unauthorized
disclosure to peers inside the network (as the transport layer itself does
to prevent unauthorized disclosure to peers outside the network), it is necessary
to add an additional end to end layer of encryption to hide the message from
the outbound tunnel endpoint and the inbound tunnel gateway. This "<a href="#op.garlic">garlic
encryption</a>" lets Alice's router wrap up multiple messages into a single
"garlic message", encrypted to a particular public key so that intermediary
peers cannot determine either how many messages are within the garlic, what
those messages say, or where those individual cloves are destined. For typical
end to end communication between Alice and Bob, the garlic will be encrypted
to the public key published in Bob's leaseSet, allowing the message to be
encrypted without giving out the public key to Bob's own router.
</p>
<p>
Another important fact to keep in mind is that I2P is entirely message based
and that some messages may be lost along the way. Applications using I2P can
use the message oriented interfaces and take care of their own congestion
control and reliability needs, but most would be best served by reusing the
provided <a href="#app.streaming">streaming</a> library to view I2P as a streams
based network.
</p>
<h2 id="op.tunnels">Tunnels</h2>
<p>
Both inbound and outbound tunnels work along similar principles.
The tunnel gateway accumulates a number of tunnel messages, eventually preprocessing
them into something for tunnel delivery. Next, the gateway encrypts that preprocessed
data and forwards it to the first hop. That peer and subsequent tunnel participants
add on a layer of encryption after verifying that it isn't a duplicate before
forward it on to the next peer. Eventually, the message arrives at the endpoint
where the messages are split out again and forwarded on as requested. The
difference arises in what the tunnel's creator does - for inbound tunnels,
the creator is the endpoint and they simply decrypt all of the layers added,
while for outbound tunnels, the creator is the gateway and they pre-decrypt
all of the layers so that after all of the layers of per-hop encryption are
added, the message arrives in the clear at the tunnel endpoint.
</p>
<p>
The choice of specific peers to pass on messages as well as their particular
ordering is important to understanding both I2P's anonymity and performance
characteristics. While the network database (below) has its own criteria for
picking what peers to query and store entries on, tunnel creators may use any peers
in the network in any order (and even any number of times) in a single tunnel.
If perfect latency and capacity data were globally known, selection and ordering
would be driven by the particular needs of the client in tandem with their
threat model. Unfortunately, latency and capacity data is not trivial to gather
anonymously, and depending upon untrusted peers to provide this information
has its own serious anonymity implications.
</p>
<p>
From an anonymity perspective, the simplest technique would be to pick peers
randomly from the entire network, order them randomly and use those peers
in that order for all eternity. From a performance perspective, the simplest
technique would be to pick the fastest peers with the necessary spare capacity,
spreading the load across different peers to handle transparent failover,
and to rebuild the tunnel whenever capacity information changes. While the
former is both brittle and inefficient, the later requires inaccessible information
and offers insufficient anonymity. I2P is instead working on offering a range
of peer selection strategies, coupled with anonymity aware measurement code
to organize the peers by their profiles.
</p>
<p>
As a base, I2P is constantly profiling the peers with which it interacts
with by measuring their indirect behavior - for instance, when a peer responds
to a netDb lookup in 1.3 seconds, that round trip latency is recorded in the
profiles for all of the routers involved in the two tunnels (inbound and outbound)
through which the request and response passed, as well as the queried peer's
profile. Direct measurement, such as transport layer latency or congestion,
is not used as part of the profile, as it can be manipulated and associated
with the measuring router, exposing them to trivial attacks. While gathering
these profiles, a series of calculations are run on each to summarize its
performance - its latency, capacity to handle lots of activity, whether they
are currently overloaded, and how well integrated into the network they seem
to be. These calculations are then compared for active peers to organize the
routers into four tiers - fast and high capacity, high capacity, not failing,
and failing. The thresholds for those tiers are determined dynamically, and
while they currently use fairly simple algorithms, alternatives exist.
</p>
<p> Using this profile data, the simplest reasonable peer selection strategy
is to pick peers randomly from the top tier (fast and high capacity), and
this is currently deployed for client tunnels. Exploratory tunnels (used for
netDb and tunnel management) pick peers randomly from the "not failing" tier
(which includes routers in 'better' tiers as well), allowing the peer to sample
routers more widely, in effect optimizing the peer selection through randomized
hill climbing. These strategies alone do however leak information regarding
the peers in the router's top tier through predecessor and netDb harvesting
attacks. In turn, several alternatives exist which, while not balancing the
load as evenly, will address the attacks mounted by particular classes of
adversaries.
</p>
<p>
By picking a random key and ordering the peers according to their XOR distance
from it, the information leaked is reduced in predecessor and harvesting attacks
according to the peers' failure rate and the tier's churn. Another simple
strategy for dealing with netDb harvesting attacks is to simply fix the inbound
tunnel gateway(s) yet randomize the peers further on in the tunnels. To deal
with predecessor attacks for adversaries which the client contacts, the outbound
tunnel endpoints would also remain fixed. The selection of which peer to fix
on the most exposed point would of course need to have a limit to the duration,
as all peers fail eventually, so it could either be reactively adjusted or
proactively avoided to mimic a measured mean time between failures of other
routers. These two strategies can in turn be combined, using a fixed exposed
peer and an XOR based ordering within the tunnels themselves. A more rigid
strategy would fix the exact peers and ordering of a potential tunnel, only
using individual peers if all of them agree to participate in the same way
each time. This varies from the XOR based ordering in that the predecessor
and successor of each peer is always the same, while the XOR only makes sure
their order doesn't change.
</p>
<p>
As mentioned before, I2P currently (release 0.8) includes the tiered
random strategy above, with XOR-based ordering. A
more detailed discussion of the mechanics involved in tunnel operation, management,
and peer selection can be found in the <a href="tunnel-alt.html">tunnel spec</a>.
</p>
<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="{{ site_url('docs/how/networkdatabase') }}">the networkdatabase</a> page,
but a basic explanation is available below.
</p>
<p>
A percentage of I2P users are appointed as 'floodfill peers'.
Currently, I2P installations that have a lot of bandwidth and are fast enough,
will appoint themselves as floodfill as soon as the number of existing floodfill routers
drops too low.
</p>
<p>
Other I2P routers will store their data and lookup data by sending simple 'store' and 'lookup' queries to the floodfills.
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="{{ 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>
<p>
Two types of information are stored in the network database.
<ul>
<li>A <b>routerInfo</b> stores information on a specific I2P router and how to contact it</li>
<li>A <b>leaseSet</b> stores information on a specific destination (e.g. I2P website, e-mail server...)</li>
</ul>
All of this information is signed by the publishing party and verified by any I2P router using or storing the information.
In addition, the data contains timing information, to avoid storage of old entries and possible attacks.
This is also why I2P bundles the necessary code for maintaining the correct time, occasionally querying some SNTP servers
(the <a href="http://www.pool.ntp.org/">pool.ntp.org</a> round robin by default)
and detecting skew between routers at the transport layer.
</p>
<p>
Some additional remarks are also important.
<ul>
<li>
<b>Unpublished and encrypted leasesets:</b>
<p>
One could only want specific people to be able to reach a destination.
This is possible by not publishing the destination in the netDb. You will however have to transmit the destination by other means.
An alternative are the 'encrypted leaseSets'. These leaseSets can only be decoded by people with access to the decryption key.
</p>
</li>
<li>
<b>Bootstrapping:</b>
<p>
Bootstrapping the netDb is quite simple. Once a router manages to receive a single routerInfo of a reachable peer,
it can query that router for references to other routers in the network.
Currently, a number of users post their routerInfo files to a website to make this information available.
I2P automatically connects to one of these websites to gather routerInfo files and bootstrap.
</p>
</li>
<li>
<b>Lookup scalability:</b>
<p>
Lookups in the I2P network are not forwarded to other netDb routers.
Currently, this is not a major problem, since the network is not very large.
However, as the network grows, not all routerInfo and leaseSet files will be present
on each netDb router. This will cause a deterioration of the percentage of successful lookups.
Because of this, refinements to the netDb will be done in the next releases.
</p>
</li>
</ul>
</p>
<h2 id="op.transport">Transport protocols</h2>
<p> Communication between routers needs to provide confidentiality and integrity
against external adversaries while authenticating that the router contacted
is the one who should receive a given message. The particulars of how routers
communicate with other routers aren't critical - three separate protocols
have been used at different points to provide those bare necessities. </p>
<p> I2P started with a TCP-based protocol which
has since been disabled. Then, to accommodate the need for high degree communication
(as a number of routers will end up speaking with many others), I2P moved
from a TCP based transport to a <a href="udp.html">UDP-based one</a> - "Secure
Semireliable UDP", or "SSU". </p>
<p> As described in the <a href="udp.html">SSU spec</a>:</p>
<blockquote> The goal of this protocol is to provide secure, authenticated,
semireliable and unordered message delivery, exposing only a minimal amount
of data easily discernible to third parties. It should support high degree
communication as well as TCP-friendly congestion control and may include
PMTU detection. It should be capable of efficiently moving bulk data at rates
sufficient for home users. In addition, it should support techniques for addressing
network obstacles, like most NATs or firewalls. </blockquote>
<p> Following the introduction of SSU, after issues with congestion collapse
appeared, a new NIO-based TCP transport called <a href="ntcp.html">NTCP</a>
was implemented. It is enabled by default for outbound connections only. Those
who configure their NAT/firewall to allow inbound connections and specify
the external host and port (dyndns/etc is ok) on /config.jsp can receive inbound
connections. As NTCP is NIO based, so it doesn't suffer from the 1 thread
per connection issues of the old TCP transport. </p>
<p> I2P supports multiple transports simultaneously. A particular transport
for an outbound connection is selected with "bids". Each transport bids for
the connection and the relative value of these bids assigns the priority.
Transports may reply with different bids, depending on whether there is already
an established connection to the peer. </p>
<p> The current implementation ranks NTCP as the highest-priority transport
for outbound connections in most situations. SSU is enabled for both outbound
and inbound connections. Your firewall and your I2P router must be configured
to allow inbound NTCP connections. For further information see the <a href="ntcp.html">NTCP
page</a>. </p>
<h2 id="op.crypto">Cryptography</h2>
<p> A bare minimum set of cryptographic primitives are combined together to
provide I2P's layered defenses against a variety of adversaries. At the lowest
level, inter router communication is protected by the transport layer security
- SSU encrypts each packet with AES256/CBC with both an explicit IV and MAC
(HMAC-MD5-128) after agreeing upon an ephemeral session key through a 2048bit
Diffie-Hellman exchange, station-to-station authentication with the other
router's DSA key, plus each network message has their own hash for local integrity
checking. <a href="#op.tunnels">Tunnel</a> messages passed over the transports
have their own layered AES256/CBC encryption with an explicit IV and verified
at the tunnel endpoint with an additional SHA256 hash. Various other messages
are passed along inside "garlic messages", which are encrypted with ElGamal/AES+SessionTags
(explained below). </p>
<h3 id="op.garlic">Garlic messages</h3>
<p> Garlic messages are an extension of "onion" layered encryption, allowing
the contents of a single message to contain multiple "cloves" - fully formed
messages alongside their own instructions for delivery. Messages are wrapped
into a garlic message whenever the message would otherwise be passing in cleartext
through a peer who should not have access to the information - for instance,
when a router wants to ask another router to participate in a tunnel, they
wrap the request inside a garlic, encrypt that garlic to the receiving router's
2048bit ElGamal public key, and forward it through a tunnel. Another example
is when a client wants to send a message to a destination - the sender's router
will wrap up that data message (alongside some other messages) into a garlic,
encrypt that garlic to the 2048bit ElGamal public key published in the recipient's
leaseSet, and forward it through the appropriate tunnels. </p>
<p> The "instructions" attached to each clove inside the encryption layer includes
the ability to request that the clove be forwarded locally, to a remote router,
or to a remote tunnel on a remote router. There are fields in those instructions
allowing a peer to request that the delivery be delayed until a certain time
or condition has been met, though they won't be honored until the <a href="#future.variablelatency">nontrivial
delays</a> are deployed. It is possible to explicitly route garlic messages
any number of hops without building tunnels, or even to reroute tunnel messages
by wrapping them in garlic messages and forwarding them a number of hops prior
to delivering them to the next hop in the tunnel, but those techniques are
not currently used in the existing implementation. </p>
<h3 id="op.sessiontags">Session tags</h3>
<p> As an unreliable, unordered, message based system, I2P uses a simple combination
of asymmetric and symmetric encryption algorithms to provide data confidentiality
and integrity to garlic messages. As a whole, the combination is referred
to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe
the simple use of 2048bit ElGamal, AES256, SHA256 and 32 byte nonces. </p>
<p> The first time a router wants to encrypt a garlic message to another router,
they encrypt the keying material for an AES256 session key with ElGamal and
append the AES256/CBC encrypted payload after that encrypted ElGamal block.
In addition to the encrypted payload, the AES encrypted section contains the
payload length, the SHA256 hash of the unencrypted payload, as well as a number
of "session tags" - random 32 byte nonces. The next time the sender wants
to encrypt a garlic message to another router, rather than ElGamal encrypt
a new session key they simply pick one of the previously delivered session
tags and AES encrypt the payload like before, using the session key used with
that session tag, prepended with the session tag itself. When a router receives
a garlic encrypted message, they check the first 32 bytes to see if it matches
an available session tag - if it does, they simply AES decrypt the message,
but if it does not, they ElGamal decrypt the first block. </p>
<p> Each session tag can be used only once so as to prevent internal adversaries
from unnecessarily correlating different messages as being between the same
routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses
when and how many tags to deliver, prestocking the recipient with enough tags
to cover a volley of messages. Garlic messages may detect the successful tag
delivery by bundling a small additional message as a clove (a "delivery status
message") - when the garlic message arrives at the intended recipient and
is decrypted successfully, this small delivery status message is one of the
cloves exposed and has instructions for the recipient to send the clove back
to the original sender (through an inbound tunnel, of course). When the original
sender receives this delivery status message, they know that the session tags
bundled in the garlic message were successfully delivered. </p>
<p> Session tags themselves have a very short lifetime, after which they are
discarded if not used. In addition, the quantity stored for each key is limited,
as are the number of keys themselves - if too many arrive, either new or old
messages may be dropped. The sender keeps track whether messages using session
tags are getting through, and if there isn't sufficient communication it may
drop the ones previously assumed to be properly delivered, reverting back
to the full expensive ElGamal encryption. </p>
<p> One alternative is to transmit only a single session tag, and from that,
seed a deterministic PRNG for determining what tags to use or expect. By keeping
this PRNG roughly synchronized between the sender and recipient (the recipient
precomputes a window of the next e.g. 50 tags), the overhead of periodically
bundling a large number of tags is removed, allowing more options in the space/time
tradeoff, and perhaps reducing the number of ElGamal encryptions necessary.
However, it would depend upon the strength of the PRNG to provide the necessary
cover against internal adversaries, though perhaps by limiting the amount
of times each PRNG is used, any weaknesses can be minimized. At the moment,
there are no immediate plans to move towards these synchronized PRNGs. </p>
<h1 id="future">Future</h1>
<p> While I2P is currently functional and sufficient for many scenarios, there
are several areas which require further improvement to meet the needs of those
facing more powerful adversaries as well as substantial user experience optimization.
</p>
<h2 id="future.restricted">Restricted route operation</h2>
<p> I2P is an overlay network designed to be run on top of a functional packet
switched network, exploiting the end to end principle to offer anonymity and
security. While the Internet no longer fully embraces the end to end principle
(due to the usage of NAT),
I2P does require a substantial portion of the network to be reachable - there
may be a number of peers along the edges running using restricted routes,
but I2P does not include an appropriate routing algorithm for the degenerate
case where most peers are unreachable. It would, however work on top of a
network employing such an algorithm. </p>
<p> Restricted route operation, where there are limits to what peers are reachable
directly, has several different functional and anonymity implications, dependent
upon how the restricted routes are handled. At the most basic level, restricted
routes exist when a peer is behind a NAT or firewall which does not allow
inbound connections. This was largely addressed in I2P 0.6.0.6 by integrating
distributed hole punching into the transport layer, allowing people behind
most NATs and firewalls to receive unsolicited connections without any configuration.
However, this does not limit the exposure of the peer's IP address to routers
inside the network, as they can simply get introduced to the peer through
the published introducer. </p>
<p> Beyond the functional handling of restricted routes, there are two levels
of restricted operation that can be used to limit the exposure of one's IP
address - using router-specific tunnels for communication, and offering 'client
routers'. For the former, routers can either build a new pool of tunnels or
reuse their exploratory pool, publishing the inbound gateways to some of them
as part of their routerInfo in place of their transport addresses. When a
peer wants to get in touch with them, they see those tunnel gateways in the
netDb and simply send the relevant message to them through one of the published
tunnels. If the peer behind the restricted route wants to reply, it may do
so either directly (if they are willing to expose their IP to the peer) or
indirectly through their outbound tunnels. When the routers that the peer
has direct connections to want to reach it (to forward tunnel messages, for
instance), they simply prioritize their direct connection over the published
tunnel gateway. The concept of 'client routers' simply extends the restricted
route by not publishing any router addresses. Such a router would not even
need to publish their routerInfo in the netDb, merely providing their self
signed routerInfo to the peers that it contacts (necessary to pass the router's
public keys). Both levels of restricted route operation are planned for I2P
2.0. </p>
<p> There are tradeoffs for those behind restricted routes, as they would likely
participate in other people's tunnels less frequently, and the routers which
they are connected to would be able to infer traffic patterns that would not
otherwise be exposed. On the other hand, if the cost of that exposure is less
than the cost of an IP being made available, it may be worthwhile. This, of
course, assumes that the peers that the router behind a restricted route contacts
are not hostile - either the network is large enough that the probability
of using a hostile peer to get connected is small enough, or trusted (and
perhaps temporary) peers are used instead. </p>
<h2 id="future.variablelatency">Variable latency</h2>
<p> Even though the bulk of I2P's initial efforts have been on low latency communication,
it was designed with variable latency services in mind from the beginning.
At the most basic level, applications running on top of I2P can offer the
anonymity of medium and high latency communication while still blending their
traffic patterns in with low latency traffic. Internally though, I2P can offer
its own medium and high latency communication through the garlic encryption
- specifying that the message should be sent after a certain delay, at a certain
time, after a certain number of messages have passed, or another mix strategy.
With the layered encryption, only the router that the clove exposed the delay
request would know that the message requires high latency, allowing the traffic
to blend in further with the low latency traffic. Once the transmission precondition
is met, the router holding on to the clove (which itself would likely be a
garlic message) simply forwards it as requested - to a router, to a tunnel,
or, most likely, to a remote client destination. </p>
<p> There are a substantial number of ways to exploit this capacity for high
latency comm in I2P, but for the moment, doing so has been scheduled for the
I2P 3.0 release. In the meantime, those requiring the anonymity that high
latency comm can offer should look towards the application layer to provide
it. </p>
<h2 id="future.open">Open questions</h2>
<pre>
How to get rid of the timing constraint?
Can we deal with the sessionTags more efficiently?
What, if any, batching/mixing strategies should be made available on the tunnels?
What other tunnel peer selection and ordering strategies should be available?
</pre>
<h1 id="similar">Similar systems</h1>
<p> I2P's architecture builds on the concepts of message oriented middleware,
the topology of DHTs, the anonymity and cryptography of free route mixnets,
and the adaptability of packet switched networking. The value comes not from
novel concepts of algorithms though, but from careful engineering combining
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="{{ site_url('docs/how/networkcomparisons') }}">Network Comparisons Page</a>.
</p>
<h2 id="similar.tor">Tor</h2>
<p><i><a href="http://www.torproject.org/">website</a></i></p>
<p> At first glance, Tor and I2P have many functional and anonymity related
similarities. While I2P's development began before we were aware of the early
stage efforts on Tor, many of the lessons of the original onion routing and
ZKS efforts were integrated into I2P's design. Rather than building an essentially
trusted, centralized system with directory servers, I2P has a self organizing
network database with each peer taking on the responsibility of profiling
other routers to determine how best to exploit available resources. Another
key difference is that while both I2P and Tor use layered and ordered paths
(tunnels and circuits/streams), I2P is fundamentally a packet switched network,
while Tor is fundamentally a circuit switched one, allowing I2P to transparently
route around congestion or other network failures, operate redundant pathways,
and load balance the data across available resources. While Tor offers the
useful outproxy functionality by offering integrated outproxy discovery and
selection, I2P leaves such application layer decisions up to applications
running on top of I2P - in fact, I2P has even externalized the TCP-like streaming
library itself to the application layer, allowing developers to experiment
with different strategies, exploiting their domain specific knowledge to offer
better performance. </p>
<p> From an anonymity perspective, there is much similarity when the core networks
are compared. However, there are a few key differences. When dealing with
an internal adversary or most external adversaries, I2P's simplex tunnels
expose half as much traffic data than would be exposed with Tor's duplex circuits
by simply looking at the flows themselves - an HTTP request and response would
follow the same path in Tor, while in I2P the packets making up the request
would go out through one or more outbound tunnels and the packets making up
the response would come back through one or more different inbound tunnels.
While I2P's peer selection and ordering strategies should sufficiently address
predecessor attacks, should a switch to bidirectional tunnels be necessary,
we could simply build an inbound and outbound tunnel along the same routers.</p>
<p> Another anonymity issue comes up in Tor's use of telescopic tunnel creation,
as simple packet counting and timing measurements as the cells in a circuit
pass through an adversary's node exposes statistical information regarding
where the adversary is within the circuit. I2P's unidirectional tunnel creation
with a single message so that this data is not exposed. Protecting the position
in a tunnel is important, as an adversary would otherwise be able to mount
a series of powerful predecessor, intersection, and traffic confirmation attacks.
</p>
<p> Tor's support for a second tier of "onion proxies" does offer a non-trivial
degree of anonymity while requiring a low cost of entry, while I2P will not
offer this topology until <a href="#future.restricted">2.0</a>. </p>
<p> On the whole, Tor and I2P complement each other in their focus - Tor works
towards offering high speed anonymous Internet outproxying, while I2P works
towards offering a decentralized resilient network in itself. In theory, both
can be used to achieve both purposes, but given limited development resources,
they both have their strengths and weaknesses. The I2P developers have considered
the steps necessary to modify Tor to take advantage of I2P's design, but concerns
of Tor's viability under resource scarcity suggest that I2P's packet switching
architecture will be able to exploit scarce resources more effectively. </p>
<h2 id="similar.freenet">Freenet</h2>
<p><i><a href="http://www.freenetproject.org/">website</a></i></p>
<p> Freenet played a large part in the initial stages of I2P's design - giving
proof to the viability of a vibrant pseudonymous community completely contained
within the network, demonstrating that the dangers inherent in outproxies
could be avoided. The first seed of I2P began as a replacement communication
layer for Freenet, attempting to factor out the complexities of a scalable,
anonymous and secure point to point communication from the complexities of
a censorship resistant distributed data store. Over time however, some of
the anonymity and scalability issues inherent in Freenet's algorithms made
it clear that I2P's focus should stay strictly on providing a generic anonymous
communication layer, rather than as a component of Freenet. Over the years,
the Freenet developers have come to see the weaknesses in the older design,
prompting them to suggest that they will require a "premix" layer to offer
substantial anonymity. In other words, Freenet needs to run on top of a mixnet
such as I2P or Tor, with "client nodes" requesting and publishing data through
the mixnet to the "server nodes" which then fetch and store the data according
to Freenet's heuristic distributed data storage algorithms. </p>
<p> Freenet's functionality is very complementary to I2P's, as Freenet natively
provides many of the tools for operating medium and high latency systems,
while I2P natively provides the low latency mix network suitable for offering
adequate anonymity. The logic of separating the mixnet from the censorship-
resistant distributed data store still seems self-evident from an engineering,
anonymity, security, and resource allocation perspective, so hopefully the
Freenet team will pursue efforts in that direction, if not simply reusing
(or helping to improve, as necessary) existing mixnets like I2P or Tor. </p>
<p> It is worth mentioning that there has recently been discussion and work
by the Freenet developers on a "globally scalable darknet" using restricted
routes between peers of various trust. While insufficient information has
been made publicly available regarding how such a system would operate for
a full review, from what has been said the anonymity and scalability claims
seem highly dubious. In particular, the appropriateness for use in hostile
regimes against state level adversaries has been tremendously overstated,
and any analysis on the implications of resource scarcity upon the scalability
of the network has seemingly been avoided. Further questions regarding susceptibility
to traffic analysis, trust and other topics do exist, but a more in-depth
review of this "globally scalable darknet" will have to wait until the Freenet
team makes more information available. </p>
<h1 id="app">Appendix A: Application layer</h1>
<p>
I2P itself doesn't really do much - it simply sends messages to remote destinations
and receives messages targeting local destinations - most of the interesting
work goes on at the layers above it. By itself, I2P could be seen as an anonymous
and secure IP layer, and the bundled <a href="#app.streaming">streaming library</a>
as an implementation of an anonymous and secure TCP layer on top of it. Beyond
that, <a href="#app.i2ptunnel">I2PTunnel</a> exposes a generic TCP proxying
system for either getting into or out of the I2P network, plus a variety of
network applications provide further functionality for end users.
</p>
<h2 id="app.streaming">Streaming library</h2>
<p>
The I2P streaming library can be viewed as a generic streaming interface (mirroring TCP sockets),
and the implementation supports a <a href="http://en.wikipedia.org/wiki/Sliding_Window_Protocol">sliding window protocol</a>
with several optimizations, to take into account the high delay over I2P.
Individual streams may adjust the maximum packet size and
other options, though the default of 4KB compressed seems a reasonable tradeoff
between the bandwidth costs of retransmitting lost messages and the latency
of multiple messages.
</p>
<p>
In addition, in consideration of the relatively high cost of subsequent
messages, the streaming library's protocol for scheduling and delivering messages
has been optimized to allow individual messages passed to contain as much
information as is available. For instance, a small HTTP transaction proxied
through the streaming library can be completed in a single round trip - the
first message bundles a SYN, FIN and the small payload (an HTTP request typically
fits) and the reply bundles the SYN, FIN, ACK and the small payload (many
HTTP responses fit). While an additional ACK must be transmitted to tell the
HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy can
deliver the full response to the browser immediately.
</p>
<p>
On the whole, however, the streaming library bears much resemblance to an
abstraction of TCP, with its sliding windows, congestion control algorithms
(both slow start and congestion avoidance), and general packet behavior (ACK,
SYN, FIN, RST, etc).
</p>
<h2 id="app.naming">Naming library and addressbook</h2>
<p><i> For more information see the <a href="naming.html">Naming and Addressbook</a>
page.</i></p>
<p><i>Developed by: mihi, Ragnarok</i></p>
<p> Naming within I2P has been an oft-debated topic since the very beginning
with advocates across the spectrum of possibilities. However, given I2P's
inherent demand for secure communication and decentralized operation, the
traditional DNS-style naming system is clearly out, as are "majority rules"
voting systems. Instead, I2P ships with a generic naming library and a base
implementation designed to work off a local name to destination mapping, as
well as an optional add-on application called the "addressbook". The addressbook
is a web-of-trust-driven secure, distributed, and human readable naming system,
sacrificing only the call for all human readable names to be globally unique
by mandating only local uniqueness. While all messages in I2P are cryptographically
addressed by their destination, different people can have local addressbook
entries for "Alice" which refer to different destinations. People can still
discover new names by importing published addressbooks of peers specified
in their web of trust, by adding in the entries provided through a third party,
or (if some people organize a series of published addressbooks using a first
come first serve registration system) people can choose to treat these addressbooks
as name servers, emulating traditional DNS. </p>
<p> I2P does not promote the use of DNS-like services though, as the damage
done by hijacking a site can be tremendous - and insecure destinations have
no value. DNSsec itself still falls back on registrars and certificate authorities,
while with I2P, requests sent to a destination cannot be intercepted or the
reply spoofed, as they are encrypted to the destination's public keys, and
a destination itself is just a pair of public keys and a certificate. DNS-style
systems on the other hand allow any of the name servers on the lookup path
to mount simple denial of service and spoofing attacks. Adding on a certificate
authenticating the responses as signed by some centralized certificate authority
would address many of the hostile nameserver issues but would leave open replay
attacks as well as hostile certificate authority attacks. </p>
<p> Voting style naming is dangerous as well, especially given the effectiveness
of Sybil attacks in anonymous systems - the attacker can simply create an
arbitrarily high number of peers and "vote" with each to take over a given
name. Proof-of-work methods can be used to make identity non-free, but as
the network grows the load required to contact everyone to conduct online
voting is implausible, or if the full network is not queried, different sets
of answers may be reachable. </p>
<p> As with the Internet however, I2P is keeping the design and operation of
a naming system out of the (IP-like) communication layer. The bundled naming
library includes a simple service provider interface which alternate naming
systems can plug into, allowing end users to drive what sort of naming tradeoffs
they prefer. </p>
<h2 id="app.syndie">Syndie</h2>
<p><i> The old Syndie bundled with I2P has been replaced by the new Syndie which
is distributed separately. For more information see the <a href="http://syndie.i2p2.de/">Syndie</a>
pages.</i></p>
<p> Syndie is a safe, anonymous blogging / content publication / content aggregation
system. It lets you create information, share it with others, and read posts
from those you're interested in, all while taking into consideration your
needs for security and anonymity. Rather than building its own content distribution
network, Syndie is designed to run on top of existing networks, syndicating
content through eepsites, Tor hidden services, Freenet freesites, normal websites,
usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie
is done so as to offer pseudonymous authentication to anyone reading or archiving
it. </p>
<h2 id="app.i2ptunnel">I2PTunnel</h2>
<p><i>Developed by: mihi</i></p>
<p> I2PTunnel is probably I2P's most popular and versatile client application,
allowing generic proxying both into and out of the I2P network. I2PTunnel
can be viewed as four separate proxying applications - a "client" which receives
inbound TCP connections and forwards them to a given I2P destination, an "httpclient"
(aka "eepproxy") which acts like an HTTP proxy and forwards the requests to
the appropriate I2P destination (after querying the naming service if necessary),
a "server" which receives inbound I2P streaming connections on a destination
and forwards them to a given TCP host+port, and an "httpserver" which extends
the "server" by parsing the HTTP request and responses to allow safer operation.
There is an additional "socksclient" application, but its use is not encouraged
for reasons previously mentioned. </p>
<p> I2P itself is not an outproxy network - the anonymity and security concerns
inherent in a mix net which forwards data into and out of the mix have kept
I2P's design focused on providing an anonymous network which capable of meeting
the user's needs without requiring external resources. However, the I2PTunnel
"httpclient" application offers a hook for outproxying - if the hostname requested
doesn't end in ".i2p", it picks a random destination from a user-provided
set of outproxies and forwards the request to them. These destinations are
simply I2PTunnel "server" instances run by volunteers who have explicitly
chosen to run outproxies - no one is an outproxy by default, and running an
outproxy doesn't automatically tell other people to proxy through you. While
outproxies do have inherent weaknesses, they offer a simple proof of concept
for using I2P and provide some functionality under a threat model which may
be sufficient for some users. </p>
<p> I2PTunnel enables most of the applications in use. An "httpserver" pointing
at a webserver lets anyone run their own anonymous website (or "eepsite")
- a webserver is bundled with I2P for this purpose, but any webserver can
be used. Anyone may run a "client" pointing at one of the anonymously hosted
IRC servers, each of which are running a "server" pointing at their local
IRCd and communicating between IRCds over their own "client" tunnels. End
users also have "client" tunnels pointing at <a href="#app.i2pmail">I2Pmail's</a>
POP3 and SMTP destinations (which in turn are simply "server" instances pointing
at POP3 and SMTP servers), as well as "client" tunnels pointing at I2P's CVS
server, allowing anonymous development. At times people have even run "client"
proxies to access the "server" instances pointing at an NNTP server. </p>
<h2 id="app.i2pbt">i2p-bt</h2>
<p><i>Developed by: duck, et al</i></p>
<p> i2p-bt is a port of the mainline python BitTorrent client to run both the
tracker and peer communication over I2P. Tracker requests are forwarded through
the eepproxy to eepsites specified in the torrent file while tracker responses
refer to peers by their destination explicitly, allowing i2p-bt to open up
a <a href="#app.streaming">streaming lib</a> connection to query them for
blocks. </p>
<p> In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making
a few modifications as necessary to strip any anonymity-compromising information
from the application and to take into consideration the fact that IPs cannot
be used for identifying peers. </p>
<h2 id="app.i2psnark">I2PSnark</h2>
<p><i>I2PSnark developed: jrandom, et al, ported from <a
href="http://www.klomp.org/mark/">mjw</a>'s <a
href="http://www.klomp.org/snark/">Snark</a> client</i></p>
<p> Bundled with the I2P install, I2PSnark offers a simple anonymous BitTorrent
client with multitorrent capabilities, exposing all of the functionality through
a plain HTML web interface. </p>
<h2 id="app.robert">Robert</h2>
<p><i>Developed by: sponge</i></p>
<p>Robert is a Bittorrent client written in Python.
It is hosted on <a href="http://bob.i2p/Robert.html">http://bob.i2p/Robert.html</a></p> <!-- TODO: expand -->
<h2 id="app.pybit">PyBit</h2>
<p><i>Developed by: Blub</i></p>
<p>PyBit is a Bittorrent client written in Python.
It is hosted on <a href="http://pebcache.i2p/">http://pebcache.i2p/</a></p> <!-- TODO: expand -->
<h2 id="app.i2phex">I2Phex</h2>
<p><i>Developed by: sirup</i></p>
<p> I2Phex is a fairly direct port of the Phex Gnutella filesharing client to
run entirely on top of I2P. While it has disabled some of Phex's functionality,
such as integration with Gnutella webcaches, the basic file sharing and chatting
system is fully functional. </p>
<h2 id="app.imule">iMule</h2>
<p><i>Developed by: mkvore</i></p>
<p> iMule is a fairly direct port of the aMule filesharing client
running entirely inside I2P.</p>
<h2 id="app.i2pmail">I2Pmail/susimail</h2>
<p><i>Developed by: postman, susi23, mastiejaner</i></p>
<p> I2Pmail is more a service than an application - postman offers both internal
and external email with POP3 and SMTP service through I2PTunnel instances
accessing a series of components developed with mastiejaner, allowing people
to use their preferred mail clients to send and receive mail pseudonymously.
However, as most mail clients expose substantial identifying information,
I2P bundles susi23's web based susimail client which has been built specifically
with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers transparent
virus filtering as well as denial of service prevention with hashcash augmented
quotas. In addition, each user has control of their batching strategy prior
to delivery through the mail.i2p outproxies, which are separate from the mail.i2p
SMTP and POP3 servers - both the outproxies and inproxies communicate with
the mail.i2p SMTP and POP3 servers through I2P itself, so compromising those
non-anonymous locations does not give access to the mail accounts or activity
patterns of the user. At the moment the developers work on a decentralized
mailsystem, called "v2mail". More information can be found on the eepsite
<a href="http://hq.postman.i2p/">hq.postman.i2p</a>.</p>
<h2 id="app.i2pbote">I2P-Bote</h2>
<p><i>Developed by: HungryHobo</i></p>
<p>
I2P-Bote is a distributed e-mail application. It does not use the traditional
e-mail concept of sending an e-mail to a server and retrieving it from a server.
Instead, it uses a Kademlia Distributed Hash Table to store mails.
One user can push a mail into the DHT, while another can request the e-mail from the DHT.
And all the mails sent within the I2P-Bote network are automatically encrypted end-to-end. <br>
Furthermore, I2P-Bote offers a remailer function on top of I2P, for increased high-latency anonymity.
</p>
<h2 id="app.i2pmessenger">I2P-Messenger</h2>
<p>
I2P-Messenger is an end-to-end encrypted serverless communication application.
For communication between two users, they need to give each other their destination keys, to allow the other to connect.
It supports file transfer and has a search for other users, based on Seedless.
</p>
{% endblock %}

8
i2p2www/pages/site/impressum.html Normal file
View File

@@ -0,0 +1,8 @@
{% extends "global/layout.html" %}
{% block title %}Impressum{% endblock %}
{% block content %}
<p>[German laws...]</p>
<p>Tassilo Schweyer<br />
Weitfelderweg 8b<br />
89275 Elchingen</p>
{% endblock %}

56
i2p2www/pages/site/index.html Normal file
View File

@@ -0,0 +1,56 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}The Invisible Internet Project{% endtrans %}{% endblock %}
{% block content_outer %}
<div class="main">
<h1>{% trans %}What does I2P do for you?{% endtrans %}</h1>
<p>{% trans %}The I2P network provides strong privacy protections for communication over the Internet. Many activities that would risk your privacy on the public Internet can be conducted anonymously on I2P.{% endtrans %}</p>
<a class="get-i2p" href="{{ url_for('downloads_list', lang=g.lang) }}">{% trans version='0.9.2' %}Get I2P {{ version }}{% endtrans %}</a>
</div>
<div class="aside-wrap">
<div class="aside">
<h1>{% trans %}Who Uses I2P?{% endtrans %}</h1>
<p>{% trans %}I2P is used by many people who care about their privacy, as well as those in high-risk situations such as:{% endtrans %}</p>
<ul>
<li><a href='#'>{{ _('Activists') }}</a></li>
<li><a href='#'>{{ _('Oppressed People') }}</a></li>
<li><a href='#'>{{ _('Journalists') }}</a></li>
<li><a href='#'>{{ _('Whistleblowers') }}</a></li>
<li><a href='#'>{{ _('The Privacy-Conscious') }}</a></li>
<li><a href='#'>{{ _('Ur Mom') }}</a></li>
</ul>
</div>
<div class="aside">
<h1>{{ _('Supported Software') }}</h1>
<ul>
<li>
<a href="supported_applications_email.html">Email</a> Integrated web mail interface, plugin for serverless email.
</li>
<li>
<a href="supported_applications_web_browsing.html">Web browsing</a> Anonymous websites, gateways to and from the public Internet.
</li>
<li>
<a href="supported_applications_blogging_and_forums.html">Blogging and forums</a> Blogging and Syndie plugins.
</li>
<li>
<a href="supported_applications_website_hosting.html">Website hosting</a> Integrated anonymous web server.
</li>
<li>
<a href="supported_applications_real_time_chat.html">Real-time chat</a> Instant messaging and IRC clients.
</li>
<li>
<a href="supported_applications_file_sharing.html">File sharing</a> ED2K and Gnutella clients, integrated BitTorrent client.
</li>
<li>
<a href="supported_applications_decentralized_file_storage.html">Decentralized file storage</a> Tahoe-LAFS distributed filesystem plugin.
</li>
<li>
<a href="supported_applications.html"><em>More supported applications&hellip;</em></a>
</li>
</ul>
</div>
<div class="aside">
<h1>{% trans %}News &amp; Updates{% endtrans %}</h1>
{% include "blog/latest.html" %}
</div>
</div>
{% endblock %}

645
i2p2www/pages/site/support/faq.html Normal file
View File

@@ -0,0 +1,645 @@
{% extends "global/layout.html" %}
{% block title %}Frequently Asked Questions{% endblock %}
{% block content %}
<h3 id="index"> Index </h3>
<ol>
<li style="list-style: none; display: inline">
<h4>General</h4>
</li>
<li><a href="#systems">What systems will I2P run on?</a></li>
<li><a href="#eepsite">Whats an "eepsite" and how do I configure my browser so I can use them?</a></li>
<li><a href="#peers">My router has very few active peers, is this OK?</a></li>
<li><a href="#active">What do the Active x/y numbers mean in the router console?</a></li>
<li><a href="#vary">My active peers / known peers / participating tunnels / connections / bandwidth vary dramatically over time! Is anything wrong?</a></li>
<li><a href="#proxy_safe">Is using an outproxy safe?</a></li>
<li><a href="#down">Most of the eepsites within I2P are down?</a></li>
<li><a href="#ports">What ports does I2P use?</a></li>
<li><a href="#port32000">Why is I2P listening for connections on port 32000?</a></li>
<li><a href="#bug">I think I found a bug, where can I report it?</a></li>
<li><a href="#jrandom">What happened to *.i2p.net? What happened to jrandom? Is I2P dead?</a></li>
<li><a href="#question">I have a question!</a></li>
<li style="list-style: none; display: inline">
<h4>Setup</h4>
</li>
<li><a href="#reseed">My router has been up for several minutes and has zero or very few connections</a></li>
<li><a href="#slow">Why is I2P so slow?</a></li>
<li><a href="#subscriptions">I'm missing lots of hosts in my addressbook. What are some good subscription links?</a></li>
<li><a href="#myeepsite">How do I set up my own eepsite?</a></li>
<li><a href="#snark">Bittorrent / I2PSnark / Azureus I2P Plugin Questions?</a></li>
<li><a href="#irc">How do I connect to IRC within I2P?</a></li>
<li><a href="#outproxy">I can't access regular Internet sites through I2P.</a></li>
<li><a href="#https">I can't access https:// or ftp:// sites through I2P.</a></li>
<li><a href="#socks">Is it possible to use I2P as a SOCKS proxy?</a></li>
<li><a href="#browserproxy">How do I configure my browser?</a></li>
<li><a href="#remote_webconsole">How can I access the web console from my other machines or password protect it?</a></li>
<li><a href="#remote_i2cp">How can I use applications from my other machines?</a></li>
<li><a href="#manual_reseed">How do I reseed manually?</a></li>
<li><a href="#cpu">My router is using too much CPU?!?</a></li>
<li style="list-style: none; display: inline">
<h4>Misconception</h4>
</li>
<li><a href="#proxy_other">How do I access IRC, BitTorrent, or other services on the regular Internet?</a></li>
<li><a href="#exit">Is my router an "exit node"(outproxy) to the regular Internet? I don't want it to be.</a></li>
<li><a href="#content">I am opposed to certain types of content. How do I keep from distributing, storing, or accessing them?</a></li>
<li style="list-style: none; display: inline">
<h4>Errors and Their Solutions</h4>
</li>
<li><a href="#compat6x">I'm using FreeBSD and when I start I2P I receive an error about <code>libm.so.4</code>!</a></li>
<li><a href="#protocolfamily">In <code>wrapper.log</code> I see an error stating <code>Protocol family unavailable</code> when I2P is loading</a></li>
</ol>
<h3 id="systems">What systems will I2P run on?
<span class="permalink">(<a href="#systems">link</a>)</span></h3>
<p>While I2P has been reported to run PCs as meagre as a low-end Pentium II with 64 MB of RAM, you'll have a much better experience on a Pentium III (or better) with 128MB of RAM (or more). A <a href="http://trac.i2p2.de/wiki/java">chart comparing the performance</a> of the various JREs can be found at <a href="http://trac.i2p2.de/wiki/java">http://trac.i2p2.de/wiki/java</a>, but in short: it's at all possible, use Sun/Oracle Java or OpenJDK.</p>
<p>I2P has been tested on Windows, Linux, FreeBSD (see the note <a href="#compat6x">below</a>), OSX, and OpenSolaris. There is work underway to bring I2P to the Android platform.</p>
<h3 id="bug">I think I found a bug, where can I report it?
<span class="permalink">(<a href="#bug">link</a>)</span></h3>
Here are some places, pick one or more.
<ul>
<li><a href="http://trac.i2p2.de/report/1">trac.i2p2.de</a> ticket (preferred method)</li>
<li><a href="http://pastethis.i2p/">pastethis.i2p</a> and follow up on IRC in #i2p</li>
<li>Discuss with the developers on IRC in #i2p-dev</li></ul>
<p>
Please include relevant information from the router logs and wrapper logs.
</p>
<h3 id="subscriptions">I'm missing lots of hosts in my addressbook. What are some good subscription links?
<span class="permalink">(<a href="#subscriptions">link</a>)</span></h3>
<p>
The default subscription is to http://www.i2p2.i2p/hosts.txt which is updated rarely.
If you don't have another subscription, you may often have to use "jump" links which
is annoying.</p>
<p>Here are some other public addressbook subscription links. You may wish to add one or two
to your <a href="http://localhost:7657/susidns/subscriptions.jsp">susidns subscription list</a>.
You don't need to add all of them, as they sync with each other periodically.
The links using a cgi-bin application employ various strategies to minimize
the number of duplicate addresses delivered, so they should be more efficient.
Note that subscribing to a hosts.txt service is an act of "trust", as a malicious
subscription could give you incorrect addresses. So think about whether you
want to trust any of these.
The operators of these services may have various policies for listing hosts.
Presence on this list does not imply endorsement.</p>
<div class="links">
<ul>
<li><a href="http://i2host.i2p/cgi-bin/i2hostetag">http://i2host.i2p/cgi-bin/i2hostetag</a></li>
<li><a href="http://stats.i2p/cgi-bin/newhosts.txt">http://stats.i2p/cgi-bin/newhosts.txt</a></li>
</div>
<h3 id="jrandom">What happened to *.i2p.net? What happened to jrandom? Is I2P dead?
<span class="permalink">(<a href="#jrandom">link</a>)</span></h3>
<p>Jrandom was the lead developer of I2P and
<a href="http://syndie.i2p2.de/">Syndie</a> for several years.
We do not know if or when jrandom will return.
The *.i2p.net domains were left in a non-functioning state after a power
outage at the hosting company.</p>
<p>See <a href="jrandom-awol.html">this page</a> for jrandom's parting message and additional information
on the migration of *.i2p.net to <a href="index.html">this website</a>.</p>
<p>I2P remains in active development.</p>
<h3 id="cpu">My router is using too much CPU?!?
<span class="permalink">(<a href="#cpu">link</a>)</span></h3>
<p>
There are many possible causes of high CPU usage. Here is a checklist:
</p><ul>
<li>
Try to use either OpenJDK or Sun/Oracle Java if it's available for your system. You can check
which version of java you have installed by typing <code>java -version</code> at a
command/shell prompt. Performance tends to suffer with other implementations of java.
</li>
<li>
Are you running a BitTorrent client over I2P? Try reducing the number of torrents, the bandwidth limits,
or try turning it off completely to see if that helps.
</li>
<li>
Are your bandwidth limits set too high? It is possible that too much traffic is going through your
I2P router and it is overloaded. Try reducing the setting for <em>share bandwidth percentage</em> on the <a href="http://localhost:7657/config">configuration</a> page.
</li>
<li>
Make sure that you're running the latest version of I2P to get the benefits of increased performance and bug fixes.
</li>
<li>
Has enough memory been set aside for use by I2P? Look at the memory graph on <a href="http://localhost:7657/graphs">the graphs page</a> to see
if the memory usage is "pegged"&mdash;the JVM is spending most of its time in
garbage collection. Increase the setting <code>wrapper.java.maxmemory</code> in <code>wrapper.config</code>.
</li>
<li>
Is the CPU usage simply higher than you would like, or is it pegged at 100% for a long time?
If it's pegged, this could be a bug. Look in the logs for clues.
</li>
<li>
You may be using the Java-based BigInteger library instead of the native version,
especially if you are running on a new or unusual OS or hardware (OpenSolaris, mipsel, etc.).
See the <a href="jbigi.html">jbigi page</a> for instructions on
diagnosing, building, and testing methods.
</li>
<li>
If your native jbigi library is working fine, the biggest user of
CPU may be routing traffic for participating tunnels. This uses CPU
because at each hop a layer of encryption must be decoded.
You can limit participating traffic in two ways - by reducing the
share bandwidth on
<a href="http://localhost:7657/confignet.jsp">confignet.jsp</a>,
or by setting <tt>router.maxParticipatingTunnels=nnn</tt> on
<a href="http://localhost:7657/configadvanced.jsp">configadvanced.jsp</a>.
</li></ul>
<h3 id="content">I am opposed to certain types of content. How do I keep from distributing, storing, or accessing them?
<span class="permalink">(<a href="#content">link</a>)</span></h3>
<p>
Hmm. I2P is an anonymous network, so that's a tricky one.
I2P is designed to withstand censorship, providing a means for everyone to communicate freely.
The best way to keep your PC free of (encrypted) traffic that you dislike is to not use I2P.
Freedom of speech has some costs.
But let's address your question in three parts:</p>
<ul>
<li><b>Distribution</b> - All traffic on I2P is encrypted in multiple layers. You don't know
a message's contents, source, or destination.
All traffic you route is internal to the I2P network, you are not an <a href="#exit">exit node</a> (outproxy).
Your only alternative is to refuse to route
<i>any</i> traffic, by setting your share bandwidth or maximum participating tunnels to 0 (see above).
It would be nice if you didn't do this, you should help the network by routing traffic for others.
Over 95% of users route traffic for others.
</li><li><b>Storage</b> - I2P does not do distributed storage of content. You must be thinking of
<a href="http://freenetproject.org/">Freenet</a>.
Nobody's content is being stored on your computer by running I2P.
</li>
<li><b>Access</b> - If there are some eepsites you don't like, don't go there.
Or, use a blocking proxy like Privoxy or some type of "net nanny".
</li></ul>
<h3 id="vary">My active peers / known peers / participating tunnels / connections / bandwidth vary dramatically over time! Is anything wrong?
<span class="permalink">(<a href="#vary">link</a>)</span></h3>
<p>
No. This is normal.
All routers adjust dynamically to changing network conditions and demands.
</p>
<h3 id="reseed">My router has been up for several minutes and has zero or very few connections
<span class="permalink">(<a href="#reseed">link</a>)</span></h3>
<p>
You may need to reseed your I2P router. With recent versions of I2P you can go to <a href="http://localhost:7657/configreseed">http://localhost:7657/configreseed</a> and click the <em>Save Changes and Reseed Now</em> button. If this method doesn't work&mdash;or you're using a very old version&mdash;you may need to <a href="#manual_reseed">reseed manually</a>.</p>
<p>
The reseed URL changed a few years ago. If this is your first install and you have installed
an old (0.6.1.30 or earlier) release, or
you have not run I2P in a long time, you must change the URL and then
click "Reseed" on the console to find other routers.
After your router is running,
on <a href="http://localhost:7657/configadvanced.jsp">configadvanced.jsp</a>,
add the line <tt>i2p.reseedURL=http://netdb.i2p2.de/</tt>
OR <tt>i2p.reseedURL=http://i2pdb.tin0.de/netDb/</tt> (either should work),
then click "Apply", then click the "reseed" link on the left.
</p><p>
This works if you are running 0.6.1.27 or later.
If you are running release 0.6.1.31 or later, you probably don't need to do this.
If you are running release 0.6.1.26 or earlier, either follow the
<a href="#manual_reseed">manual reseed instructions</a> below
or install the <a href="download">latest release</a>.
Possible alternate method - add
<tt>wrapper.java.additional.5=-Di2p.reseedURL=http://netdb.i2p2.de/</tt>
to wrapper.config, shutdown the router completely, then start again, then click "reseed".
Let us know if this works.
</p>
<p>...but you *really* should <a href="download">upgrade</a> to the latest version.</p>
<h3 id="peers">My router has very few active peers, is this OK?
<span class="permalink">(<a href="#peers">link</a>)</span></h3>
<p>
If your router has 10 or more active peers, everything is fine. Changes in releases 0.6.1.31 and 0.6.1.32 improved the
efficiency of the router and effectively reduced the number of active peers.
The router <i>should</i> maintain connections to a few peers at all times.
The best way to stay "better-connected" to the network is to <a href="http://localhost:7657/config">share more bandwidth</a>.
</p>
<h3 id="exit">Is my router an "exit node" to the regular Internet? I don't want it to be.
<span class="permalink">(<a href="#exit">link</a>)</span></h3>
<p>
No. Unlike <a href="http://www.torproject.org/">Tor</a>,
"exit nodes" or "outproxies" are not an inherent part of the network.
Only volunteers who set up and run separate applications will relay traffic to the regular Internet.
There are very, very few of these.
</p>
<h3 id="outproxy">I can't access regular Internet sites through I2P.
<span class="permalink">(<a href="#outproxy">link</a>)</span></h3>
<p>
See above. There are very few HTTP "outproxies", they are not an inherent part of the network,
and they may not be up.
In addition, the old outproxies squid.i2p, true.i2p, and krabs.i2p have vanished.
The only outproxy at the moment is false.i2p.
To use it, edit your <a href="http://localhost:7657/i2ptunnel/edit.jsp?tunnel=0">i2ptunnel settings for eepProxy</a>
and set your outproxy list to 'false.i2p' (only).
Then stop and restart the eepProxy.
If it doesn't work, the outproxy is not up. It is not I2P's fault.
If your primary reason to use an anonymous network is to anonymously access sites
on the regular Internet, you should probably try <a href="http://www.torproject.org/">Tor</a>.
</p>
<h3 id="https">I can't access https:// or ftp:// sites through I2P.
<span class="permalink">(<a href="#https">link</a>)</span></h3>
<p>
Within I2P, there is no need for HTTPS, as all traffic is encrypted end-to-end.
FTP is not supported for technical reasons.
</p><p>
There are no FTP "outproxies" to the Internet&mdash;it may not even be possible to set up one.
Any other kind of outproxy may work if it's set up with a standard tunnel.
If you would like to set up some type of outproxy, carefully research the potential risks.
The I2P community may or may not be able to help with the technical aspects, feel free to ask.</p>
<p>As explained several times above, any existing outproxy isn't a core part of the network.
They are services run by individuals and they may or may not
be operational at any given time.
</p>
<p><b>Update</b>: Thanks to the work of h2ik, there is an https outproxy available for use via I2P. Starting with I2P 0.8.4 <a href="http://localhost:7657/i2ptunnel/edit?tunnel=6">the tunnel</a> is configured out of the box.<br />
In case the https outproxy is not available in your version of I2P, you can add it easily by doing the following:</p>
<ol><li>Open <a href="http://localhost:7657/i2ptunnel/index.jsp">i2p tunnel manager</a>. Scroll down to the bottom.
</li><li>Choose <b>CONNECT</b> from <b>New Client Tunnel</b> dropdown list, click <b>Create</b>
</li><li>In the new page, <b>name</b> and <b>describe</b> your new https tunnel as you like.
The <b>Access Point</b> is your local port for the new https proxy recommended port's <b>4445</b>.
<b>Outproxy</b> should be the outproxy's .i2p address which supports https.
See this forum post of <a href="http://forum.i2p/viewtopic.php?p=31356#31356">h2ik</a>'s for the address.
Make sure <b>Shared Client</b>, <b>Delay Connect</b>, <b>AutoStart</b> are checked.
Other options should be left at the defaults. Click Save. In tunnel manger, click the <b>Start</b> button next to your new tunnel.
</li><li>In firefox, click through <b>Tools</b>><b>Options</b>><b>Advanced</b>><b>Network</b>><b>Setting</b>.
Untick <b>Use this proxy for all protocol</b>, set <b>SSL proxy:</b> to localhost:4445.
</li><li>Done.
</li></ol>
<h3 id="proxy_safe">Is using an outproxy safe?
<span class="permalink">(<a href="#proxy_safe">link</a>)</span></h3>
<p>
This is a question that only you can answer because the correct answer depends on your behaviours, your
<a href="{{ site_url('docs/how/threatmodel') }}">threat model</a>, and how much you trust the outproxy operator.
</p><p>
Like Tor, I2P does not magically encrypt the Internet.
You are vulnerable to snooping by the outproxy operators.
The <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ExitEavesdroppers">Tor FAQ</a>
does a good job of explaining this.
</p><p>
In addition, you may be vulnerable to collusion between the outproxy operator
and operators of other I2P services, if you use the same tunnels ("shared clients").
There is additional discussion about this on <a href="http://zzz.i2p/topics/217">zzz.i2p</a>.
</p>
<h3 id="proxy_other">How do I access IRC, BitTorrent, or other services on the regular Internet?
<span class="permalink">(<a href="#proxy_other">link</a>)</span></h3>
<p>
Unless an outproxy has been set up for the service you want to connect to, this cannot be done.
There are only three types of outproxies running right now: HTTP, HTTPS, and email. Note that there is not a SOCKS outproxy.
If this type of service is required, try <a href="http://www.torproject.org/">Tor</a>.
</p>
<h3 id="down">Most of the eepsites within I2P are down?
<span class="permalink">(<a href="#down">link</a>)</span></h3>
<p>
If you consider every eepsite that has ever been created, yes, most of them are down.
People and eepsites come and go.
A good way to get started in I2P is check out a list of eepsites that are currently up.
<a href="http://perv.i2p/stats.cgi">perv.i2p</a> tracks active eepsites.
</p>
<h3 id="myeepsite">How do I set up my own eepsite?
<span class="permalink">(<a href="#myeepsite">link</a>)</span></h3>
<p>
Click on the <a href="http://localhost:7658/">Website</a> link
at the top of your router console for instructions.
</p>
<h3 id="slow">Why is I2P so slow?
<span class="permalink">(<a href="#slow">link</a>)</span></h3>
<p>
Why are downloads, torrents, web browsing, and everything else so slow on I2P?
The encryption and routing within the I2P network adds a substantial amount of overhead and limits bandwidth.
Anonymity isn't free.
</p>
<p>
In addition, you and everybody else probably need to increase your bandwidth limits.
Two key settings are the inbound and outbound bandwidth limiters on
<a href="http://localhost:7657/config.jsp">the configuration page</a>.
With the default settings of 32KBps you will generally get no better than 15KBps data transfer in I2PSnark.
Increasing the settings (but keeping within your actual connection limitations)
will increase the potential transfer rate for I2PSnark and all other applications.
</p><p>
Also, do you have sufficient share bandwidth configured to allow participating tunnels
to route through your router? Believe it or not, allowing participating traffic
keeps you well-integrated in the network and helps your own transfer speeds.
</p><p>
I2P is a work in progress. Lots of improvements and fixes are being implemented, and
generally speaking, running the latest release will help your performance.
If you haven't, <a href="download.html">install the latest release</a>.
</p>
<h3 id="snark">Bittorrent / I2PSnark / Azureus I2P Plugin Questions?
<span class="permalink">(<a href="#snark">link</a>)</span></h3>
<p>
See the
<a href="http://forum.i2p/viewtopic.php?t=2068">I2P Bittorrent FAQ</a>
<a href="http://forum.i2p2.de/viewtopic.php?t=2068">(outside I2P)</a>
</p>
<h3 id="irc">How do I connect to IRC within I2P?
<span class="permalink">(<a href="#irc">link</a>)</span></h3>
<p>
On the
<a href="http://localhost:7657/i2ptunnel/index.jsp">I2PTunnel configuration page</a>,
start the ircProxy.
Then tell your IRC client to connect to localhost port 6668.
</p>
<h3 id="remote_webconsole">How can I access the web console from my other machines or password protect it?
<span class="permalink">(<a href="#remote_webconsole">link</a>)</span></h3>
<p>
For security purposes, the router's admin console by default only listens
for connections on the local interface. However, with a little hacking,
you can make it reachable remotely:
</p>
<ol>
<li>Open <code>~/.i2p/clients.config</code> and replace<br />
<code>clientApp.0.args=7657 ::1,127.0.0.1 ./webapps/</code><br />
with <br />
<code>clientApp.0.args=7657 0.0.0.0 ./webapps/</code></li>
<li>Go to <a href="http://localhost:7657/configadvanced.jsp">http://localhost:7657/configadvanced.jsp</a>
and add a new option: <code>consolePassword=foo</code> (or whatever password you want)</li>
<li>Go to <a href="http://localhost:7657/index.jsp">http://localhost:7657/index.jsp</a>
and hit "Graceful restart", which restarts the JVM and reloads the client applications</li>
</ol>
<p>
After that fires up, you should now be able to reach your console remotely.
You will be prompted for a username and password though - the username is
"admin" and the password is whatever you specified in step 2 above. Note: the
<code>0.0.0.0</code> above specifies an <i>interface</i>, not a network or netmask. 0.0.0.0
means "bind to all interfaces", so it can be reachable on 127.0.0.1:7657 as well as
any LAN/WAN IP.
</p>
<h3 id="remote_i2cp">How can I use applications from my other machines?
<span class="permalink">(<a href="#remote_i2cp">link</a>)</span></h3>
<p>
By default, the router I2CP interface (port 7654) binds to address 127.0.0.1. To bind to 0.0.0.0, set the
router advanced configuration option <tt>i2cp.tcp.bindAllInterfaces=true</tt> and restart.
</p>
<h3 id="eepsite">Whats an "eepsite"?
<span class="permalink">(<a href="#eepsite">link</a>)</span></h3>
<p>
An eepsite is a website that is hosted anonymously - you can access it by
setting your web browser's HTTP proxy to use the web proxy (typically it
listens on localhost port 4444), and browsing to the site.
</p>
<h3 id="browserproxy">How do I configure my browser?
<span class="permalink">(<a href="#browserproxy">link</a>)</span></h3>
<p>
The proxy config for different browsers is on a <a href="htproxyports.html">
separate page</a> with screenshots. More advanced configs with external tools
are possible but could introduce leaks in your setup.
</p>
<h3 id="active">What do the Active x/y numbers mean in the router console?
<span class="permalink">(<a href="#active">link</a>)</span></h3>
<p>
x is the number of peers you've sent or received a message from
successfully in the last minute, y is the number of peers seen in the last
hour or so.
</p>
<h3 id="socks">Is it possible to use I2P as a SOCKS proxy?
<span class="permalink">(<a href="#socks">link</a>)</span></h3>
<p>
The SOCKS proxy is working as of release 0.7.1. SOCKS 4/4a/5 are supported.
There is no SOCKS outproxy so it is of limited use.
</p><p>
In addition, many applications leak sensitive
information that could identify you on the Internet. I2P only filters
connection data, but if the program you intend to run sends this
information as content, I2P has no way to protect your anonymity. For
example, some mail applications will send the IP address of the machine
they are running on to a mail server. There is no way for I2P to filter
this, thus using I2P to 'socksify' existing applications is possible, but
extremely dangerous.
</p><p>
If you would like more information on the socks proxy application anyway,
there are some helpful hints on the <a href="socks.html">socks page</a>.
</p>
<h3 id="ports">What ports does I2P use?
<span class="permalink">(<a href="#ports">link</a>)</span></h3>
<p>
Okay, here's a rundown of the default ports (everything is configurable
through various settings, of course):
</p>
<ul>
<li><b>Internet-facing ports</b>
Note: New installs as of release 0.7.8 do not use port 8887; they select a random port
between 9000 and 31000 when the program is run for the first time.
The selected port is shown on the router <a href="http://127.0.0.1:7657/confignet.jsp">configuration page.</a>
<ul>
<li><b>Outbound UDP from the random port noted on the <a href="http://127.0.0.1:7657/confignet.jsp">configuration page</a> to arbitrary remote UDP ports, allowing replies</b></li>
<li><b>Outbound TCP from random high ports to arbitrary remote TCP ports</b></li>
<li><b>(optional, but recommended) Inbound UDP to the port noted on <a href="http://127.0.0.1:7657/confignet.jsp">configuration page</a> from arbitrary locations</b></li>
<li><b>(optional, but recommended) Inbound TCP to the port noted on <a href="http://127.0.0.1:7657/confignet.jsp">configuration page</a> from arbitrary locations</b><br />
Inbound TCP may be disabled on the <a href="http://127.0.0.1:7657/confignet.jsp">configuration page.</a></li>
<li><b>Outbound UDP on port 123, allowing replies</b><br />
This is necessary for I2P's internal time sync (via SNTP -
querying a random SNTP host in pool.ntp.org or another
server you specify)</li>
</ul>
</li>
</ul>
<ul>
<li><b>Local I2P ports</b>, listening only to local connections by default,
except where noted:
<ul>
<li><b>1900:</b> UPnP SSDP UDP multicast listener.
<i>Cannot be changed. Binds to all interfaces.
May be disabled on <a href="http://localhost:7657/confignet.jsp">confignet.jsp</a>.
</i></li>
<li><b>2827:</b> BOB bridge, a higher level socket API for clients
<i>Disabled by default.
May be enabled/disabled on <a href="http://localhost:7657/configclients.jsp">configclients.jsp</a>.
May be changed in the bob.config file.
</i></li>
<li><b>4444:</b> HTTP proxy
<i>May be disabled or changed on the i2ptunnel page in the router console.
May also be configured to be bound to a specific interface or all interfaces.
</i></li>
<li><b>4445:</b> HTTPS proxy
<i>May be disabled or changed on the i2ptunnel page in the router console.
May also be configured to be bound to a specific interface or all interfaces.
</i></li>
<li><b>6668:</b> IRC proxy
<i>May be disabled or changed on the i2ptunnel page in the router console.
May also be configured to be bound to a specific interface or all interfaces.
</i></li>
<li><b>7652:</b> UPnP HTTP TCP event listener.
<i>Binds to the LAN address.
May be changed with advanced config i2np.upnp.HTTPPort=nnnn.
May be disabled on <a href="http://localhost:7657/confignet.jsp">confignet.jsp</a>.
</i></li>
<li><b>7653:</b> UPnP SSDP UDP search response listener.
<i>Binds to all interfaces.
May be changed with advanced config i2np.upnp.SSDPPort=nnnn.
May be disabled on <a href="http://localhost:7657/confignet.jsp">confignet.jsp</a>.
</i></li>
<li><b>7654:</b> I2P Client Protocol port, used by client apps.
<i>May be changed to a different port on
<a href="http://localhost:7657/configclients.jsp">configclients.jsp</a>
but this is not recommended.
May be to bind to a different interface or all interfaces, or disabled, on
<a href="http://localhost:7657/configclients.jsp">configclients.jsp</a>.
</i></li>
<li><b>7655:</b> UDP for SAM bridge, a higher level socket API for clients
<i>Only opened when a SAM V3 client requests a UDP session.
May be enabled/disabled on <a href="http://localhost:7657/configclients.jsp">configclients.jsp</a>.
May be changed in the clients.config file with the SAM command line option sam.udp.port=nnnn.
</i></li>
<li><b>7656:</b> SAM bridge, a higher level socket API for clients
<i>Disabled by default for new installs as of release 0.6.5.
May be enabled/disabled on <a href="http://localhost:7657/configclients.jsp">configclients.jsp</a>.
May be changed in the clients.config file.
</i></li>
<li><b>7657:</b> Your router console
<i>May be disabled in the clients.config file.
May also be configured to be bound to a specific interface or all interfaces in that file.
</i></li>
<li><b>7658:</b> Your eepsite
<i>May be disabled in the clients.config file.
May also be configured to be bound to a specific interface or all interfaces in the jetty.xml file.
</i></li>
<li><b>7659:</b> Outgoing mail to smtp.postman.i2p
<i>May be disabled or changed on the i2ptunnel page in the router console.
May also be configured to be bound to a specific interface or all interfaces.
</i></li>
<li><b>7660:</b> Incoming mail from pop.postman.i2p
<i>May be disabled or changed on the i2ptunnel page in the router console.
May also be configured to be bound to a specific interface or all interfaces.
</i></li>
<li><b>8998:</b> mtn.i2p2.i2p (Monotone - disabled by default)
<i>May be disabled or changed on the i2ptunnel page in the router console.
May also be configured to be bound to a specific interface or all interfaces.
</i></li>
<li><b>31000:</b> Local connection to the wrapper control channel port.
<i>Outbound to 32000 only, does not listen on this port.
Starts at 31000 and will increment until 31999 looking for a free port.
To change, see the
<a href="http://wrapper.tanukisoftware.com/doc/english/prop-port.html">wrapper documentation</a>.
For more information see <a href="#port32000">below</a>.
</i></li>
<li><b>32000:</b> Local control channel for the service wrapper.
<i>To change, see the
<a href="http://wrapper.tanukisoftware.com/doc/english/prop-port.html">wrapper documentation</a>.
For more information see <a href="#port32000">below</a>.
</i></li>
</ul>
</li>
</ul>
<p>
The local I2P ports and the I2PTunnel ports do not need to be reachable from
remote machines, but *should* be reachable locally. You can also create
additional ports for I2PTunnel instances via http://localhost:7657/i2ptunnel/
(and in turn, would need to get your firewall to allow you local access, but
not remote access, unless desired).
</p>
<p>
So, to summarize, nothing needs to be reachable by unsolicited remote peers, but
if you can configure your NAT/firewall to allow inbound UDP and TCP the <a href="http://localhost:7657/config">outbound facing port</a>, you'll
get better performance. You will also need to be able to send outbound UDP packets
to arbitrary remote peers (blocking IPs randomly with something like PeerGuardian
only hurts you - don't do it).
</p>
<h3 id="port32000">Why is I2P listening on port 32000?
<span class="permalink">(<a href="#port32000">link</a>)</span></h3>
<p>The Tanuki java service wrapper that we use opens this port&mdash;bound to localhost&mdash;in order
to communicate with software running inside the JVM. When the JVM is launched it is given a key
so it can connect to the wrapper. After the JVM establishes its connection
to the wrapper, the wrapper refuses any additional connections.</p>
<p>More information can be found in the
<a href="http://wrapper.tanukisoftware.com/doc/english/prop-port.html">wrapper documentation</a>.</p>
<h3 id="manual_reseed">How do I reseed manually?
<span class="permalink">(<a href="#manual_reseed">link</a>)</span></h3>
<p>
An I2P router only needs to be seeded once, to join the network for the first time.
Reseeding is nothing more than sending plain HTTP GET requests
to fetch a directory listing and download multiple "routerInfo" files
from a predefined reseed URL.
</p>
<p>
A typical symptom of a failed reseed is the "Known" indicator
(on the left sidebar of the router console) displaying a very small value
(often less than 5) which does not increase. This can occur, among other things,
if your firewall limits outbound traffic, and blocked the reseed request.
</p>
To reseed an I2P router manually, do the following:
<ul>
<li>Stop your I2P router
</li><li>Open <!-- DOWN <a href="http://i2pdb.tin0.de/netDb/">http://i2pdb.tin0.de/netDb/</a> or -->
<a href="http://netdb.i2p2.de/">http://netdb.i2p2.de/</a> using a web browser
</li><li>Save a dozen "routerInfo" files to your I2P "netDb" directory
<!-- DOWN
</li><li>Alternate method (easier): Download <a href="http://i2pdb.tin0.de/latest.zip">http://i2pdb.tin0.de/latest.zip</a>
and unzip it into your I2P "netDb" directory.
-->
</li><li>Start your I2P router
</li></ul>
<h3 id="compat6x">I'm using FreeBSD and when I start I2P I receive an error about <code>libm.so.4</code>!
<span class="permalink">(<a href="#compat6x">link</a>)</span></h3>
When trying to start the router using "i2prouter start", you may see output like the following:<br />
<code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$ ./i2prouter start<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Starting I2P Service...<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/libexec/ld-elf.so.1: Shared object "libm.so.4" not found, required by "i2psvc"
</code>
<p>In order to be inclusive and try to ensure that I2P will run on as many systems
as possible, up until I2P 0.8.9 we used a <a href="http://wrapper.tanukisoftware.com/">java wrapper</a>
compiled for FreeBSD 6.x. If you're receiving this error you most likely are missing the necessary compatibility libraries.
These libraries may be installed by performing the following steps:</p>
<ul>
<li>Switch to the root user with <code>su</code> or log in as <code>root</code>.</li>
<li><code>cd /usr/ports/misc/compat6x</code></li>
<li><code>make install</code></li>
</ul>
<p>If you cannot install these compatibility libraries (or do not want to), other possibilities would be to compile the wrapper for <a href="manualwrapper">your system</a>,
starting I2P with the <code>runplain.sh</code> script, or you can replace the wrapper with one from the source tarball.</p>
<p>For the 0.8.9 release of I2P, the wrapper was upgraded to v3.5.12 and compiled on systems running FreeBSD 7.2.</p>
<h3 id="protocolfamily">In <code>wrapper.log</code> I see an error that states "<code>Protocol family unavailable</code>" when loading the Router Console
<span class="permalink">(<a href="#protocolfamily">link</a>)</span></h3>
<p>Often this error will occur with any network enabled java software on some systems that are configured to use IPv6 by default. There are a few ways to solve this:</p>
<ul>
<li>On Linux based systems, you can <code>echo 0 > /proc/sys/net/ipv6/bindv6only</code></li>
<li>Look for the following lines in <code>wrapper.config</code>.<br />
<code>#wrapper.java.additional.5=-Djava.net.preferIPv4Stack=true<br />
#wrapper.java.additional.6=-Djava.net.preferIPv6Addresses=false<br />
</code><br />
If the lines are there, uncomment them by removing the "#"s. If the lines are not there, add them without the "#"s.<br /></li>
</ul>
Another option would be to remove the <strong>::1</strong> from <code>~/.i2p/clients.config</code>
<p><strong>WARNING</strong>: For any changes to <code>wrapper.config</code> to take effect, you must completely
stop the router and the wrapper. Clicking <em>Restart</em> on your
router console will NOT reread this file! You must
click <em>Shutdown</em>, wait 11 minutes, then start I2P.</p>
<hr />
<h3 id="question">I have a question!
<span class="permalink">(<a href="#question">link</a>)</span></h3>
<p>
Great! Find us on IRC irc.freenode.net #i2p or post to
the <a href="http://forum.i2p2.de/">forum</a> and we'll post it here (with
the answer, hopefully).
</p>
{% endblock %}

351
i2p2www/pages/site/team.html Normal file
View File

@@ -0,0 +1,351 @@
{% extends "global/layout.html" %}
{% block title %}Team{% endblock %}
{% block content %}
<h1>I2P Project Members</h1>
<p>We are a small group of people spread around several continents, working to
advance different aspects of the project and discussing the design of the
network.
<a href="{{ site_url('volunteer') }}">Get involved!</a>
</p>
<table border="0">
<tr>
<td valign="top" rowspan="18"><b>Admin</b></td>
<td valign="top"><b>Project Manager</b></td>
<td valign="top">zzz</td>
<td valign="top"><i>point of contact of last resort</i></td>
</tr>
<tr>
<td valign="top"><b>Treasurer</b></td>
<td valign="top">eche|on</td>
<td valign="top"><i>manage donations / accounts / bounties</i></td>
</tr>
<tr>
<td valign="top"><b>PR manager</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>press contact, manages public relations and affairs</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://forum.i2p/">Forum</a> admin</b></td>
<td valign="top">cervantes</td>
<td valign="top"><i>manage the public user forum</i></td>
</tr>
<tr>
<td valign="top"><b>Mirrors admin</b></td>
<td valign="top">welterde</td>
<td valign="top"><i>manage the project mirrors</i></td>
</tr>
<tr>
<td valign="top"><b><a href="{{ site_url('develop/monotone') }}">Monotone</a> guru</b></td>
<td valign="top">welterde, eche|on</td>
<td valign="top"><i>manage the public monotone repositories</i></td>
</tr>
<tr>
<td valign="top"><b>Packager; Linux</b></td>
<td valign="top">KillYourTV</td>
<td valign="top"><i>Linux (Debian/Ubuntu) distribution packager</i></td>
</tr>
<tr>
<td valign="top"><b>Packager; Windows</b></td>
<td valign="top">KillYourTV</td>
<td valign="top"><i>Windows installer packager</i></td>
</tr>
<tr>
<td valign="top"><b>Release Manager</b></td>
<td valign="top">zzz</td>
<td valign="top"><i>Builds and signs the releases</i></td>
</tr>
<tr>
<td valign="top"><b>Update admin</b></td>
<td valign="top">KillYourTV</td>
<td valign="top"><i>Monitors and recruits in-network update hosts</i></td>
</tr>
<tr>
<td valign="top"><b>Reseed admin</b></td>
<td valign="top">Meeh</td>
<td valign="top"><i>Monitors, advises and recruits reseed hosts</i></td>
</tr>
<tr>
<td valign="top"><b>Security expert</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>threat model / crypto expert</i></td>
</tr>
<tr>
<td valign="top"><b>User Advocate</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>gather, prioritize, advocate for user needs</i></td>
</tr>
<tr>
<td valign="top"><b>Web Designer</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>manage the public project website content design</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://www.i2p2.i2p/">Webserver</a> admin</b></td>
<td valign="top">welterde</td>
<td valign="top"><i>manage the public project webservers</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://www.i2p2.i2p/">Website</a> admin</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>manage the public project website content</i></td>
</tr>
<tr>
<td valign="top"><b>News Admin</b></td>
<td valign="top">eche|on</td>
<td valign="top"><i>manage router console news feed</i></td>
</tr>
<tr>
<td valign="top"><b>Director of passion</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>community motivator</i></td>
</tr>
<tr><td colspan="4"><hr /></td></tr>
<tr>
<td valign="top" rowspan="25"><b>Dev</b></td>
<td valign="top"><b>Core Lead</b></td>
<td valign="top">zzz</td>
<td valign="top"><i>lead dev for the SDK and router</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://hq.postman.i2p/">I2P mail</a> lead</b></td>
<td valign="top">postman</td>
<td valign="top"><i>organize and develop the i2p mail system</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://i2host.i2p/">I2Host</a> lead</b></td>
<td valign="top">sponge</td>
<td valign="top"><i>I2Host addressbook application</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://bob.i2p/">BOB</a> lead</b></td>
<td valign="top">sponge</td>
<td valign="top"><i>Basic Open Bridge</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://i2pbote.i2p/">I2P-Bote</a> lead</b></td>
<td valign="top">HungryHobo</td>
<td valign="top"><i>I2PBote plugin</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://bob.i2p/">Robert</a> lead</b></td>
<td valign="top">sponge</td>
<td valign="top"><i>Robert BitTorrent client</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://forum.i2p2.de/viewforum?f=25">I2Phex</a> lead</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>I2Phex Gnutella client</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://forum.i2p2.de/viewforum?f=21">I2PSnark</a> lead</b></td>
<td valign="top">zzz</td>
<td valign="top"><i>Maintains the integrated Bittorrent client</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://forum.i2p2.de/viewforum?f=30">iMule</a> lead</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>eMule client over I2P</i></td>
</tr>
<tr>
<td valign="top"><b><a href="http://forum.i2p2.de/viewforum?f=29">Syndie</a> lead</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>Syndie development</i></td>
</tr>
<tr>
<td valign="top"><b>Susimail lead</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>Susimail development</i></td>
</tr>
<tr>
<td valign="top"><b>Console</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>Router console HTML/CSS design</i></td>
</tr>
<tr>
<td valign="top"><b>SAM</b></td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>SAM maintainer</i></td>
</tr>
<tr>
<td valign="top" rowspan="8"><b>Console Translations</b></td>
<td valign="top">walking</td>
<td valign="top"><i>Chinese</i></td>
</tr>
<tr>
<td valign="top">monkeybrains</td>
<td valign="top"><i>Dutch</i></td>
</tr>
<tr>
<td valign="top" style="color:blue">magma</td>
<td valign="top"><i>French</i></td>
</tr>
<tr>
<td valign="top">eche|on, mixxy</td>
<td valign="top"><i>German</i></td>
</tr>
<tr>
<td valign="top">rus, 4get, slow</td>
<td valign="top"><i>Russian</i></td>
</tr>
<tr>
<td valign="top">user</td>
<td valign="top"><i>Spanish</i></td>
</tr>
<tr>
<td valign="top">thelastcode, hamada</td>
<td valign="top"><i>Arabic</i></td>
</tr>
<tr>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>Other languages</i></td>
</tr>
<tr>
<td valign="top" rowspan="4"><b>Contributors</b></td>
<td valign="top">cervantes</td>
<td valign="top"><i>fire2pe dev, console enhancements</i></td>
</tr>
<tr>
<td valign="top">Mathiasdm</td>
<td valign="top"><i>desktopgui, dijjer port</i></td>
</tr>
<tr>
<td valign="top">KillYourTV</td>
<td valign="top"><i>Debian/Ubuntu Packager and PPA maintainer</i></td>
</tr>
<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>
<td valign="top" rowspan="32" colspan="2"><b>Past contributors</b></td>
<td valign="top">mihi</td>
<td valign="top"><i>I2PTunnel development, ministreaming library</i></td>
</tr>
<tr>
<td valign="top">jrandom</td>
<td valign="top"><i>Project lead, Syndie lead</i></td>
</tr>
<tr>
<td valign="top">Complication</td>
<td valign="top"><i>Project lead, Syndie lead, I2Phex, support guru</i></td>
</tr>
<tr>
<td valign="top">mkvore</td>
<td valign="top"><i>iMule lead</i></td>
</tr>
<tr>
<td valign="top">redzara</td>
<td valign="top"><i>I2Phex work</i></td>
</tr>
<tr>
<td valign="top">striker</td>
<td valign="top"><i>I2Phex work</i></td>
</tr>
<tr>
<td valign="top">legion</td>
<td valign="top"><i>I2Phex work</i></td>
</tr>
<tr>
<td valign="top">Connely</td>
<td valign="top"><i>Python SAM library, attack simulations</i></td>
</tr>
<tr>
<td valign="top">mastiejaner</td>
<td valign="top"><i>i2pmail development</i></td>
</tr>
<tr>
<td valign="top">dust</td>
<td valign="top"><i>Syndie help</i></td>
</tr>
<tr>
<td valign="top">susi23</td>
<td valign="top"><i>i2p mail,susimail and susidns apps</i></td>
</tr>
<tr>
<td valign="top">sirup</td>
<td valign="top"><i>I2Phex (port of Phex to I2P)</i></td>
</tr>
<tr>
<td valign="top">Ragnarok</td>
<td valign="top"><i>addressbook,i2p-bt,syndie client</i></td>
</tr>
<tr>
<td valign="top">duck</td>
<td valign="top"><i>organize and develop the i2p-bt BitTorrent port</i></td>
</tr>
<tr>
<td valign="top">Ragnarok</td>
<td valign="top"><i>addressbook, i2p-bt, syndie client development</i></td>
</tr>
<tr>
<td valign="top">thecrypto</td>
<td valign="top"><i>encryption and signature routines, I2PIM</i></td>
</tr>
<tr>
<td valign="top">aum</td>
<td valign="top"><i>SAM jython code, work on stasher (DHT) and v2v (VoI2P)</i></td>
</tr>
<tr>
<td valign="top">hypercubus</td>
<td valign="top"><i>installer, systray, bogobot</i></td>
</tr>
<tr>
<td valign="top">ugha</td>
<td valign="top"><i>jbigi development, wiki migration, doc cleanup</i></td>
</tr>
<tr>
<td valign="top">oOo</td>
<td valign="top"><i>java debugging and client development on I2PTunnel and the router console</i></td>
</tr>
<tr>
<td valign="top">BrianR</td>
<td valign="top"><i>SAM perl module</i></td>
</tr>
<tr>
<td valign="top">eco</td>
<td valign="top"><i>i2psnark work</i></td>
</tr>
<tr>
<td valign="top">shendaras</td>
<td valign="top"><i>java cleanup</i></td>
</tr>
<tr>
<td valign="top">JAnonymous</td>
<td valign="top"><i>docs. wiki migration</i></td>
</tr>
<tr>
<td valign="top">jar</td>
<td valign="top"><i>translations into French</i></td>
</tr>
<tr>
<td valign="top">scintilla</td>
<td valign="top"><i>C port of jcpuid</i></td>
</tr>
<tr>
<td valign="top">smeghead</td>
<td valign="top"><i>C# SAM library, pants, fortuna integration</i></td>
</tr>
<tr>
<td valign="top">Nightblade</td>
<td valign="top"><i>libSAM</i></td>
</tr>
<tr>
<td valign="top">dinoman</td>
<td valign="top"><i>i2p-bt tracker development</i></td>
</tr>
<tr>
<td valign="top">DrWoo</td>
<td valign="top"><i>i2p-bt tracker development</i></td>
</tr>
<tr>
<td valign="top">dr|z3d</td>
<td valign="top"><i>Console and website themes</i></td>
</tr>
<tr>
<td valign="top" colspan="2">&hellip;and many others</td>
</tr>
</table>
{% endblock %}

36
i2p2www/pages/site/volunteer/bounties/arabic.html Normal file
View File

@@ -0,0 +1,36 @@
{% extends "global/layout.html" %}
{% block title %}Bounty Arabic translation of webpage and router console{% endblock %}
{% block content %}<p>To improve I2P usage and attract more people
into I2P echelon set out this bounty for translation
of the I2P web page and I2P router console into Arabic.
</p>
<p>
This bounty is set into 2 subparts:
<br>
Part 1 is translation of the webpage. <br>
</p>
<p>
For collecting the bounty of 20 BTC you need to translate the following pages:<br>
http://www.i2p2.de/index.html<br>
http://www.i2p2.de/download.html<br>
http://www.i2p2.de/intro.html <br>
http://www.i2p2.de/faq.html <br>
http://www.i2p2.de/bounties.html <br>
http://www.i2p2.de/getinvolved.html <br>
http://www.i2p2.de/donate.html <br>
This job was done by hamada and the bounty of 20 BTC was paid to hamada.<br>
</p>
<p>
Part 2 is the translation of the router console. The router console was
partly translated and the bounty of 80 BTC was paid to hamada.
</p>
<p>
Judge is echelon.
</p>
<p>
Note:
<p><i>bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for this translation bounty!</i></p>
{% endblock %}

20
i2p2www/pages/site/volunteer/bounties/btcclient.html Normal file
View File

@@ -0,0 +1,20 @@
{% extends "global/layout.html" %}
{% block title %}Bounty creating a I2P native Bitcoin client {% endblock %}
{% block content %}<p>For a future of I2P and attract more people
into I2P this bounty is to create a I2P native Bitcoin client.
It should integrate with other client via the I2P network and via gateways to
the existant bitcoin network.
</p>
Judge is psychonaut who donated the first 30 &euro; to this bounty.
<br>
<p>
Note:
To claim the bounty the author must not be paid by other organizations or teams
for this work (e.g. GSoC students are not valid).</p>
<p><i>Note 2: bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for the BTC I2P native client bounty!</i></p>
{% endblock %}

38
i2p2www/pages/site/volunteer/bounties/datastore.html Normal file
View File

@@ -0,0 +1,38 @@
{% extends "global/layout.html" %}
{% block title %}Bounty datastorage{% endblock %}
{% block content %}<p>To improve I2P's usage and to be independent of routers
online status we want a datastorage as a extension to I2P.
Like in Freenet the datastorage should be distributed and every
participating node should be able to configure his options.
The files should be saved in chunks and at least 2-3 times to
obtain redundancy. Usage of storage space should be auto balanced.
As it is a extra application, it should work flawless within I2P and
cooperate nice with the I2P router. Maybe a integration within the
webpage/router could be done.</p>
<br>
<p>This bounty cooperates with the 2 other bounties "frost for I2P" and
"eepsites in datastorage".</p>
<br>
<p>The frost for I2P datastorage bounty is paid for a frost like program
with which files/messages are stored into database and got from database.
It needs to work with a GUI.</p>
<br>
<p>The eepsite served out of I2P datastorage extends a I2P router to send
out eepsites out of the I2P datastorage. All files for eepsites need to be
saved inside of datastorage and are taken from it.
Extension:
For better integration all datastorage participants could serve that eepsite.
</p>
<br>
<p>
Note:
For bounties to be declared done and paid, we need the program AND the source.
Source and code need to be licensed under a free license (free to change and
free to distribute). To claim the bounty the author must not be paid by other
organizations or teams for this work (e.g. GSoC students are not valid).</p>
<p><i>Note 2: bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for the datastore bounty!</i></p>
{% endblock %}

21
i2p2www/pages/site/volunteer/bounties/debpack.html Normal file
View File

@@ -0,0 +1,21 @@
{% extends "global/layout.html" %}
{% block title %}Bounty I2P package in Debian and Ubuntu mirrors{% endblock %}
{% block content %}<p>For the future of I2P and in order to attract more people
to I2P, this bounty was set for including an I2P package into the Ubuntu and Debian
archive mirrors.
To claim this bounty, the I2P router package needs to be available from
Ubuntu and Debian archive mirrors and Debian bug
<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448638">448638</a>
needs to be closed successfully.
</p>
<br>
<p>
Note:
To claim the bounty, the author must not be paid by other organizations or teams
for this work (e.g. GSoC students are not permitted to claim it).</p>
<p><i>Note 2: Bounty amounts can be increased by further donations. Do
you think these are important? <a href="donate">Make a donation</a>,
marking the amount for the I2P Ubuntu/Debian package bounty!</i></p>
{% endblock %}

15
i2p2www/pages/site/volunteer/bounties/i2phex.html Normal file
View File

@@ -0,0 +1,15 @@
{% extends "global/layout.html" %}
{% block title %}Bounty I2PHex code implementation{% endblock %}
{% block content %}<p>To improve I2P usage and attract more people
into I2PHex P2P ArneBab setout the bounty for implementing actual
Phex code onto I2PHex.
</p>
<br>
<p>
Note:
<p><i>bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for the i2phex code implementation bounty!</i></p>
{% endblock %}

145
i2p2www/pages/site/volunteer/bounties/index.html Normal file
View File

@@ -0,0 +1,145 @@
{% extends "global/layout.html" %}
{% block title %}Bounties{% endblock %}
{% block content %}
<!-- file version 2012.04.16.01 -->
<h1>Bounties for I2P</h1>
<p>While we always gratefully accept any contributions of code,
documentation, and the like, there are other ways to help I2P move
forward. As with any open source project, our goals would be achieved more
rapidly if we were able to support all of our contributors to work on
I2P full time. However, as with any open source project, that's not a
possibility. Instead, we are making use of a bounty system, whereby
anyone can get support for working on something that people want
implemented, and people who want to contribute to I2P can be assured that
their support goes to what they care about.</p>
<p>We are also keeping open the ability for people who want to support I2P
but don't have strong feelings about the bounties available. Those people
can simply put their trust in the I2P team to do what we feel is best by
donating to a catch-all general fund that will be used as deemed
necessary - allocated to various bounties, covering incidentals (hosting,
etc), and the like.</p>
<h2>Current bounties</h2>
<table border="1">
<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="{{ site_url('volunteer/bounties/datastore') }}">Frost for I2P datastorage</a></b></p></td>
<td><p>Proposal in development</p></td>
<td><p>echelon</p></td>
<td><p>[vacant]</p></td>
<td><p>&euro;50 EUR</p></td>
</tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/datastore') }}">Eepsites served out of I2P datastorage</a></b></p></td>
<td><p>Proposal in development</p></td>
<td><p>echelon</p></td>
<td><p>[vacant]</p></td>
<td><p>&euro;50 EUR</p></td>
</tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/i2phex') }}">Backporting Phex code onto I2PHex</a></b></p></td>
<td><p>Proposal in development</p></td>
<td><p>Arne Bab</p></td>
<td><p>[vacant]</p></td>
<td><p>&euro;100 EUR</p></td>
</tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/ipv6') }}">make I2P IPv6 native</a></b></p></td>
<td><p>Proposal in development</p></td>
<td><p>Amiga4000</p></td>
<td><p>[vacant]</p></td>
<td><p>&euro;100 EUR</p></td>
</tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/debpack') }}">I2P package in Debian and Ubuntu mirrors</a></b></p></td>
<td><p>Proposal in development</p></td>
<td><p>h2ik</p></td>
<td><p>[vacant]</p></td>
<td><p>&euro;93 EUR</p></td>
</tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/btcclient') }}">Bitcoin client for I2P</a></b></p></td>
<td><p>Proposal in development</p></td>
<td><p>psychonaut</p></td>
<td><p>[vacant]</p></td>
<td><p>&euro;30 EUR and 114,24BTC</p></td>
</tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/unittests') }}">Unit tests and Multi-router Simulation</a></b></p></td>
<td><p>Partly done, partly in work, partly still open</p></td>
<td><p>anonymous</p></td>
<td><p>str4d,hottuna</p></td>
<td><p>3000 &euro;, of which 300 &euro; already paid for done jobs</p></td>
</tr>
</table>
<h2>Hold bounties, set on hold due to jrandom AWOL and missing funding</h2>
<table border="1">
<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="http://forum.i2p2.de/viewtopic.php?t=1136">Bundling bounties</a></b></p></td>
<td><p>Proposed</p></td>
<td><p>jrandom</p></td>
<td><p>[vacant]</p></td>
<td><p>$0 USD each, or $0 for all</p></td>
</tr>
</table>
<h2>Claimed bounties</h2>
<table border="1">
<tr><td><p><b>Name</b></p></td><td><p><b>Status</b></p></td><td><p><b>Dev team<sup>*</sup></b></p></td></tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/silc') }}">Setting up a SILC server</a></b></p></td>
<td><p>withdrawn and bounty divided between ReturningNovice and the general fund</p></td>
<td><p>An Anonymous Secret Society, society@mail.i2p</p></td>
</tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/arabic') }}">arabic translation</a></b></p></td>
<td><p>both parts were taken by hamada for 100 BTC</p></td>
<td><p>hamada</p></td>
</tr>
<tr>
<td><p><b><a href="{{ site_url('volunteer/bounties/datastore') }}">Datastore over I2P</a></b></p></td>
<td><p><a href="http://duck.i2p/tahoe-lafs/">CLAIMED</a> for 700 &euro;</p></td>
<td><p>duck, smeghead</p></td>
</tr>
<tr>
<td> <p><b><a href="{{ site_url('volunteer/bounties/rutrans') }}">translation into Russian</a></b></p></td>
<td><p>claimed for $230 USD sponsored by russian sponsor</p></td>
<td><p>4get</p></td>
</tr>
<tr>
<td><p><b>Swarming file transfer</b></p></td>
<td><p><a href="http://duck.i2p/i2p-bt/">CLAIMED</a> for &euro;250 EUR</p></td>
<td><p>duck, ragnarok, dinoman, connelly, drwoo</p></td>
</tr>
<tr>
<td><p><b>Streaming library window size</b></p></td>
<td><p><a href="http://dev.i2p.net/pipermail/i2p/2004-November/000491.html">Claimed</a></p></td>
<td><p>jrandom</p></td>
</tr>
<tr>
<td><p><b>IRC connect time monitor</b></p></td>
<td>CLAIMED for $10 USD</td>
<td><p>hypercubus</p></td>
</tr>
<tr>
<td><p><b>Unit tests (part 1)</b></p></td>
<td>CLAIMED for $300 USD</td>
<td><p>Comwiz</p></td>
</tr>
<tr>
<td><p><b><a href="http://gcc.gnu.org/java/">GCJ</a> support</b></p></td>
<td><p><a href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/Makefile.gcj">Claimed</a></p></td>
<td><p>jrandom</p></td>
</tr>
</table>
<p><i><sup>*</sup> Dev lists anyone who may already be working on the bounty - collaboration is preferred, so if you're interested in working on it, please contact one of the people listed!</i></p>
{% endblock %}

20
i2p2www/pages/site/volunteer/bounties/ipv6.html Normal file
View File

@@ -0,0 +1,20 @@
{% extends "global/layout.html" %}
{% block title %}Bounty I2P IPv6 native{% endblock %}
{% block content %}<p>For a future of I2P and attract more people
into I2P I withdrawal the vuze bounty and offer a IPv6 bounty.
To claim this bounty, the I2P router needs to run full on native
IPv6 connections like it does on IPv4.
</p>
<br>
<p>
Note:
For bounties to be declared done and paid, we need the plugin AND the source.
Source and code need to be licensed under a free license (free to change and
free to distribute). To claim the bounty the author must not be paid by other
organizations or teams for this work (e.g. GSoC students are not valid).</p>
<p><i>Note 2: bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for the native IPv6 I2P bounty!</i></p>
{% endblock %}

41
i2p2www/pages/site/volunteer/bounties/rutrans.html Normal file
View File

@@ -0,0 +1,41 @@
{% extends "global/layout.html" %}
{% block title %}Bounty russian translation of webpage and router console{% endblock %}
{% block content %}<p>To improve I2P usage and attract more people
into I2P a anonymous donator set out the bounty for translation
of the I2P web page and I2P router console into russian language.
</p>
<p>
This bounty is set into 2 subparts:
<br>
Part 1 is translation of the webpage. <br>
</p>
<p>
For collecting the bounty of $115 USD you need to translate the following pages:<br>
http://www.i2p2.de/index.html<br>
http://www.i2p2.de/download.html<br>
http://www.i2p2.de/intro.html <br>
http://www.i2p2.de/faq.html <br>
http://www.i2p2.de/bounties.html <br>
http://www.i2p2.de/bounty_datastore <br>
http://www.i2p2.de/bounty_i2phex <br>
http://www.i2p2.de/bounty_vuzeplugin <br>
http://www.i2p2.de/getinvolved.html <br>
http://www.i2p2.de/donate.html <br>
</p>
<p>
Part 2 is the translation of the router console. The whole router console needs
to be translated to collect the bounty of $115 USD.
</p>
<p>
Judge is the russian donor.
</p>
<a href="{{ change_lang('ru') }}">russian</a> short version of this page available.<br>
<br>
<p>
Note:
<p><i>bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for this translation bounty!</i></p>
{% endblock %}

28
i2p2www/pages/site/volunteer/bounties/silc.html Normal file
View File

@@ -0,0 +1,28 @@
{% extends "global/layout.html" %}
{% block title %}Bounty migrate I2P IRC to SILC {% endblock %}
{% block content %}
<!-- file version 2012.01.01.01 -->
<p>For a future of I2P and attract more people
into I2P this bounty is to setup and host a I2P SILC server.
This will allow people to send files over their messaging servers and have intrinsic security built into the protocol.
Judge is An Anonymous Secret Society, society@mail.i2p.
</p>
<p>
A silc server needs to be set up and run for at least 3 month time to get payed.
A second server should be set up, to.
</p>
<p>
Bounty was withdrawn and money donated to returningnovice and general fund.
</p>
<br>
<p>
Note:
To claim the bounty the author must not be paid by other organizations or teams
for this work (e.g. GSoC students are not valid).</p>
<p><i>Note 2: bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for the I2P silc server bounty!</i></p>
{% endblock %}

99
i2p2www/pages/site/volunteer/bounties/unittests.html Normal file
View File

@@ -0,0 +1,99 @@
{% extends "global/layout.html" %}
{% block title %}Bounty unittests{% endblock %}
{% block content %}
<!-- file version 2012.04.16.01 -->
<p>To improve I2P's maintainability, we want to have a solid set of
automated unit tests for the critical code. While we do have some
unit tests at the moment, they are ad-hoc and partly unfinished.
This bounty is for someone to check the existing tests and move over
old ones to jUnit, automate their execution, extend them to provide
better code coverage, and publish the report online. Its a massive
effort, but can be broken down into phases, listed below (phase 2
must occur first, but further phases may happen in any order).
As this needs some reading of code, it is the best start point for
new devs to get a good overview of I2P code and coding. A good job
for college students, interns or anyone who is just interested.
</p>
<h2>Phase 1: <a name="jenkins">CI jenkins and IRC bot</a></h2>
<b>Bounty: 500 &euro;</b><i> in work by MathiasDM</i><br />
<p>
To collect this bounty, a continuous integration server (Jenkins,
old name was Hudson) must be set up and a connected IRC bot needs
to set up in the channel #i2p-dev on IRC2p network to print out
results of build tests.<br>
The server needs to be run long term.
</p>
<br>
<h2>Phase 2: <a name="sdk">Check existing SDK tests </a></h2>
<b>Bounty: 150 &euro;</b> paid to str4d <br />
<p>
To collect this bounty, the existing SDK tests must be checked
and made to work again. The need to be integrated into the ant
build scripts ("ant test"), and tied in with a code coverage tool (e.g.
<a href="http://www.cenqua.com/clover/">Clover</a>). The ant script
must be capable of generating test status results as a web page,
which will be published online.
</p>
<br>
<h2>Phase 3: <a name="sdk_coverage">SDK test coverage</a></h2>
<b>Bounty: 200 &euro;</b> in work by str4d<br />
<p>
To collect this bounty, the automated unit tests must meet a
measured code coverage of 90% of the SDK (i2p/core/java/src).
</p>
<br>
<h2>Phase 4: <a name="router">Router test migration</a></h2>
<b>Bounty: 150 &euro;</b> paid to str4d<br />
<p>
As with phase 2, the existing unit tests for the router must be
moved over to the automated system.
</p>
<br>
<h2>Phase 5: <a name="router_coverage">Router test coverage</a></h2>
<b>Bounty: 200 &euro;</b> in work by str4d<br />
<p>
To collect this bounty, the automated unit tests must meet a
measured code coverage of 90% of the router (i2p/router/java/src).
</p>
<br>
<h2>Phase 6: <a name="streaming">Streaming lib tests</a></h2>
<b>Bounty: 300 &euro;</b><br />
<p>
To collect this bounty, a new set of unit tests must meet a
measured code coverage of 90% of the streaming lib
(i2p/apps/ministreaming/ and i2p/apps/streaming/).
</p>
<br>
<h2>Phase 7: <a name="multirouter">MultiRouter simulation</a></h2>
<b>Bounty: 1500 &euro;</b> will be split in more sub-tasks<br />
<p>
To collect this bounty, the existing in-memory multi-router
simulation must be checked, made work again and extend to simulate
lots of routers in memory on a single machine. This bounty will
be split in more fine grained subworks.
</p>
<br>
<p>
Judge on all these works is the donor and donor decides if a phase is
called succesfull done and money can be paid.
</p>
<p><i>Note: bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for the unit test bounty!</i></p>
{% endblock %}

26
i2p2www/pages/site/volunteer/bounties/vuzeplugin.html Normal file
View File

@@ -0,0 +1,26 @@
{% extends "global/layout.html" %}
{% block title %}Bounty I2P vuze plugin{% endblock %}
{% block content %}<p>To improve I2P usage and attract more people
into I2P torrent P2P I setout the bounty for a working I2P vuze
plugin.
The plugin needs to be official and submitted to vuze for publication
on their webpage/repository for plugins.
It should be easy to install and configured, work smooth and flawless.
Configuration should be friendly to starters and made easy to be anonymous.
It should work with *.b32.i2p destinations as with signed (516++ bits)
destinations.
</p>
<br>
<p>
Note:
For bounties to be declared done and paid, we need the plugin AND the source.
Source and code need to be licensed under a free license (free to change and
free to distribute). To claim the bounty the author must not be paid by other
organizations or teams for this work (e.g. GSoC students are not valid).</p>
<p><i>Note 2: bounty amounts may be increased by further donations. Do
you think these are important? <a href="donate">Add in your donation</a>,
marking the amount for the vuze plugin bounty!</i></p>
{% endblock %}

95
i2p2www/pages/site/volunteer/donate.html Normal file
View File

@@ -0,0 +1,95 @@
{% extends "global/layout.html" %}
{% block title %}Donate{% endblock %}
{% block content %}<p>Thank you for your interest in contributing to I2P!
The details of how you
can make your contribution are provided below.</p>
<h2><a href="http://www.paypal.com/">PayPal</a></h2>
<br />
You can donate direct via PayPal to the account "echelon@i2pmail.org".<br />
<br />
<table>
<tr>
<td>One time donation:</td>
<td>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post"><fieldset style="border:none;">
<input type="hidden" name="cmd" value="_s-xclick" />
<input type="hidden" name="hosted_button_id" value="3031758" />
<input type="hidden" name="no_note" value="0" />
<input type="hidden" name="no_shipping" value="1" />
<input type="image" src="https://www.paypal.com/en_US/i/btn/btn_donateCC_LG.gif" style="border:0;" name="submit" alt="" />
<img alt="" style="border:0;width:1;height:1" src="https://www.paypal.com/de_DE/i/scr/pixel.gif" /></fieldset>
</form>
</td>
</tr>
<tr>
<td>Donate 10 &euro;/month for 12 months: </td>
<td>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<fieldset style="border:none;">
<input type="hidden" name="cmd" value="_s-xclick" />
<input type="hidden" name="hosted_button_id" value="3031934" />
<input type="hidden" name="no_note" value="0" />
<input type="hidden" name="no_shipping" value="1" />
<input type="image" src="https://www.paypal.com/en_US/i/btn/btn_subscribeCC_LG.gif" style="border:0;" name="submit" alt="I2P donation" />
<img alt="" style="border:0;width:1;height:1" src="https://www.paypal.com/de_DE/i/scr/pixel.gif" /></fieldset>
</form>
</td>
</tr>
<tr>
<td>Donate 20 &euro;/month for 12 months: </td>
<td>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<fieldset style="border:none;">
<input type="hidden" name="cmd" value="_s-xclick" />
<input type="hidden" name="hosted_button_id" value="KALQ2V9SQF348" />
<input type="image" src="https://www.paypal.com/en_US/i/btn/btn_subscribeCC_LG.gif" style="border:0;" name="submit" alt="I2P donation" />
<img alt="" style="border:0;width:1;height:1" src="https://www.paypal.com/de_DE/i/scr/pixel.gif" /></fieldset>
</form>
</td>
</tr>
<tr>
<td>Donate 30 &euro;/month for 12 months: </td>
<td>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post" >
<fieldset style="border:none;">
<input type="hidden" name="cmd" value="_s-xclick" />
<input type="hidden" name="hosted_button_id" value="QSU89XWKB7N3U" />
<input type="image" src="https://www.paypal.com/en_US/i/btn/btn_subscribeCC_LG.gif" style="border:0;" name="submit" alt="I2P donation" />
<img alt="" style="border:0;width:1;height:1" src="https://www.paypal.com/de_DE/i/scr/pixel.gif" /></fieldset>
</form>
</td>
</tr>
<tr>
<td>Donate 50 &euro;/month for 12 months: </td>
<td>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<fieldset style="border:none;">
<input type="hidden" name="cmd" value="_s-xclick" />
<input type="hidden" name="hosted_button_id" value="8ENENJMVN6TL8" />
<input type="image" src="https://www.paypal.com/en_US/i/btn/btn_subscribeCC_LG.gif" style="border:0;" name="submit" alt="I2P donation" />
<img alt="" style="border:0;width:1;height:1" src="https://www.paypal.com/de_DE/i/scr/pixel.gif" /></fieldset>
</form>
</td>
</tr>
</table>
<br />
<h2><a href="http://www.flattr.com/">Flattr</a></h2>
<a href="http://flattr.com/thing/13523/Invisible-Internet-Project-I2P">
<img src="http://api.flattr.com/button/button-static-50x60.png" title="Flattr this" style="border:0;" alt="Flattr this" /></a>
<br />
<br />
<h2><a href="http://www.bitcoin.org/">Bitcoin</a></h2>
<p>As of December 2010, eche|on has been running a <a href="http://www.bitcoin.org">Bitcoin</a> account for the I2P project.
If you'd like to donate using Bitcoin, just transfer your desired amount of coins to the account
<b>1HkJCceXf7of1sTNRVJbXiZHfDTLL71Siy</b> and leave eche|on a note if you'd like your donation to be mentioned on the I2P webpage.<br />
</p>
<p>If you want to keep more or less anonymous, the option to send money via mail is also available. But it is less secure
as the envelope can be lost on the way to us. </p>
<p>If you'd like to donate via snail mail, send an email to <a href="mailto:echelon@i2pmail.org?subject=information about snailmail donation">echelon@i2pmail.org</a>
and you'll receive an email with instructions detailing how to proceed.</p>
<p>In the meantime, feel free to take a look at the generous donations that have been given in support of the I2P Project at the <a href="{{ site_url('volunteer/halloffame') }}">hall of fame</a>.</p>
{% endblock %}

376
i2p2www/pages/site/volunteer/halloffame.html Normal file
View File

@@ -0,0 +1,376 @@
{% extends "global/layout.html" %}
{% block title %}Hall Of Fame{% endblock %}
{% block content %}
<!-- file version 2012.08.01.01 -->
<h1>I2P'<small>s</small> Hall of Fame</h1>
<b>Current balance: as of 2012-08-01</b><br />
<b>General fund: 3471,5 &euro; and 1528,65311242 BTC</b><br />
<b><a href="{{ site_url('volunteer/bounties/datastore') }}">Datastorage bounty</a>: 115.0 &euro; and 2 BTC</b><br />
<b><a href="{{ site_url('volunteer/bounties/ipv6') }}">native IPv6 I2P </a>: 100.0 &euro;</b><br />
<b><a href="{{ site_url('volunteer/bounties/i2phex') }}">I2PHex bounty</a>: 60.0 &euro;</b><br />
<b><a href="{{ site_url('volunteer/bounties/debpack') }}">I2P in debian mirrors</a>: 93.0 &euro;</b><br />
<b><a href="{{ site_url('volunteer/bounties/btcclient') }}">Bitcoin client for I2P</a>: 30.0 &euro; and 117.34 BTC</b><br />
<b><a href="{{ site_url('volunteer/bounties/unittests') }}">Unit Tests for I2P router</a>: 2700 &euro;</b><br />
<br />
<b>Current monthly running costs:</b><br />
<table border="1">
<tr>
<td>Welterde</td>
<td>8 &euro;/mo, since January, 2008 - i2p2.de</td>
</tr>
<tr>
<td>eche|on</td>
<td>40 &euro;/mo since January, 2008 - i2p-projekt.de and domains</td>
</tr>
</table>
<p>Big thanks go to the following people who have donated to I2P!</p>
<p>
If you have made a donation, please send an email to <a href="mailto:echelon@i2pmail.org">echelon</a>
with your name or nick (and optionally homepage) so we can list you here.
</p>
<b>Current monthly subscriptions:</b><br />
<table border="1">
<tr><td>01/2012-01/2013</td><td>anonymous</td><td>30 &euro;</td><td>General fund</td></tr>
</table>
<br />
<b>2012 donations and costs:</b><br />
<table border="1">
<tr><td>date</td><td>who</td><td>income</td><td>outgoing</td><td>account</td></tr>
<tr><td>Jan, 2012</td><td>www.i2p2.de server rent</td><td></td><td>-100 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>www.i2p-projekt.de/echelon.i2p server rent</td><td></td><td>-200 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>I2P services sponge</td><td></td><td>-100 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>anonymous</td><td>500 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>anonymous</td><td>1500 &euro;</td><td></td><td>Bounty Unit Tests</td></tr>
<tr><td>Jan, 2012</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>anonymous</td><td>0.01 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>anonymous</td><td>100 BTC</td><td></td><td>Bounty I2P bitcoin client</td></tr>
<tr><td>Jan, 2012</td><td>anonymous</td><td>20 &euro;</td><td></td><td>Bounty .deb package</td></tr>
<tr><td>Jan, 2012</td><td>anonymous</td><td>25 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>alu-anon</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>maxkoda</td><td>1.00 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2012</td><td>maxkoda</td><td>2.00 BTC</td><td></td><td>Bounty I2P BTC client</td></tr>
<tr><td>Feb, 2012</td><td>DJ Eugene</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>ZZZ new dev workstation</td><td></td><td>522,02 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>anonymous</td><td>15 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>anonymous</td><td>91 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>Sponge dev machine</td><td></td><td>52,3 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>anonymous</td><td>22 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>domain cost</td><td></td><td>11,9 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>domain cost</td><td></td><td>11,9 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>anonymous</td><td>1.4328 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>anonymous</td><td>1000.00 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>anonymous</td><td>2.20 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>maxkoda</td><td>1.00 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2012</td><td>maxkoda</td><td>2.00 BTC</td><td></td><td>Bounty I2P BTC client</td></tr>
<tr><td>Mar, 2012</td><td>Lautrec</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Mar, 2012</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Mar, 2012</td><td>PayPal fees recalculated</td><td></td><td>188,13 &euro;</td><td>General fund</td></tr>
<tr><td>Mar, 2012</td><td>anonymous</td><td>0.25 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Mar, 2012</td><td>anonymous</td><td>2.00 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Mar, 2012</td><td>anonymous</td><td>0.0000491 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Mar, 2012</td><td>anonymous</td><td>1500 &euro;</td><td></td><td>Bounty Unit Tests</td></tr>
<tr><td>Mar, 2012</td><td>domain cost</td><td></td><td>11,9 &euro;</td><td>General fund</td></tr>
<tr><td>Mar, 2012</td><td>maxkoda</td><td>1.01 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Mar, 2012</td><td>maxkoda</td><td>2.10 BTC</td><td></td><td>Bounty I2P BTC client</td></tr>
<tr><td>Apr, 2012</td><td>anonymous</td><td>100 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2012</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2012</td><td>anonymous</td><td>0,50 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2012</td><td>anonymous</td><td>0.10 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2012</td><td>anonymous</td><td>0.723 BTC</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>0.01 BTC</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>2.00 BTC</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>1.50 BTC</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>150 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>5 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>PayPal fees april</td><td></td><td>11,94 &euro;</td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>0.25 BTC</td><td></td><td>General fund</td></tr>
<tr><td>May, 2012</td><td>anonymous</td><td>0,69307046 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jun, 2012</td><td>sell 100 BTC</td><td>513.38 &euro;</td><td>100 BTC</td><td>General fund</td></tr>
<tr><td>Jun, 2012</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jun, 2012</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jun, 2012</td><td>anonymous</td><td>10 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jun, 2012</td><td>MaxKoda</td><td>1 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jun, 2012</td><td>maxkoda</td><td>1 BTC</td><td></td><td>Bounty I2P BTC client</td></tr>
<tr><td>Jul, 2012</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jul, 2012</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jul, 2012</td><td>anonymous</td><td>1 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jul, 2012</td><td>anonymous</td><td>4 BTC</td><td></td><td>General fund</td></tr>
</table>
<br />
<br />
<b>2011 donations and costs:</b><br />
<table border="1">
<tr><td>date</td><td>who</td><td>income</td><td>outgoing</td><td>account</td></tr>
<tr><td>Jan, 2011</td><td>www.i2p2.de server rent</td><td></td><td>-100 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>www.i2p-projekt.de/echelon.i2p server rent</td><td></td><td>-200 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>PayPal fees 2010</td><td></td><td>-40 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>refund of netstorage bounty,duck,smeghead</td><td>700 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>woodchips</td><td>50 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>anonymous</td><td>13 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>anonymous</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>anonymous</td><td>400 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>Amiga4000</td><td>1000 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>anonymous</td><td>30 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>Mozartito</td><td>8 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>anonymous</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jan, 2011</td><td>Flattr</td><td>69,15 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2011</td><td>bv-falcon</td><td>15 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2011</td><td>anonymous</td><td>6,66 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2011</td><td>anonymous</td><td>100 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2011</td><td>anonymous</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2011</td><td>anonymous</td><td>25 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Feb, 2011</td><td>3 domains 2011</td><td></td><td>-36 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2011</td><td>anonymous</td><td>33.41 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Mar, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Mar, 2011</td><td>h2ik</td><td>23 &euro;</td><td></td><td>I2P deb in debian mirrors</td></tr>
<tr><td>Mar, 2011</td><td>h2ik</td><td>50 &euro;</td><td></td><td>IPv6 Bounty</td></tr>
<tr><td>Mar, 2011</td><td>hamada</td><td></td><td>-80 BTC</td><td>Arabic routerconsole</td></tr>
<tr><td>Mar, 2011</td><td>anonymous</td><td>63.01 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>I2P</td><td>745.84 &euro;</td><td>-1000 BTC</td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>magma</td><td>100 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>I2P services sponge</td><td></td><td>-100 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>anonymous</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>anonymous</td><td>50 &euro;</td><td></td><td>I2P debian package bounty</td></tr>
<tr><td>Apr, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Apr, 2011</td><td>anonymous</td><td>0.06 BTC</td><td></td><td>General fund</td></tr>
<tr><td>May, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>May, 2011</td><td>anonymous</td><td>5 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>May, 2011</td><td>anonymous</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>May, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>May, 2011</td><td>Max Koda</td><td>10 BTC</td><td></td><td>General fund</td></tr>
<tr><td>May, 2011</td><td>anonymous</td><td>1.180001 BTC</td><td></td><td>General fund</td></tr>
<tr><td>May, 2011</td><td>ZZZ</td><td></td><td>250.06 &euro;</td><td>trimslice dev device for ZZZ</td></tr>
<tr><td>Jun, 2011</td><td>An anonymous secret society society@mail.i2p</td><td>200 &euro;</td><td></td><td>SILC bounty</td></tr>
<tr><td>Jun, 2011</td><td>Flattr</td><td>104 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jun, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jun, 2011</td><td>anonymous</td><td>3 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jun, 2011</td><td>anonymous</td><td></td><td>-13.6 BTC</td><td>General fund</td></tr>
<tr><td>Jun, 2011</td><td>anonymous</td><td>22.5 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jul, 2011</td><td>hamada</td><td></td><td>-20 BTC</td><td>arabic bounty</td></tr>
<tr><td>Jul, 2011</td><td>anonymous</td><td>0.2 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Jul, 2011</td><td>psychonaut</td><td>30 &euro;</td><td></td><td>Bitcoin client bounty</td></tr>
<tr><td>Jul, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jul, 2011</td><td>anonymous</td><td>5 GBP</td><td></td><td>General fund</td></tr>
<tr><td>Jul, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Jul, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Aug, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Aug, 2011</td><td>An anonymous secret society society@mail.i2p</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Aug, 2011</td><td>anonymous</td><td>15 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Aug, 2011</td><td>ZZZ</td><td></td><td>$150 US</td><td>travel expenses for ZZZ</td></tr>
<tr><td>Sep, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Sep, 2011</td><td>anonymous</td><td>5 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Sep, 2011</td><td>maxkoda.i2p</td><td>1.303 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Sep, 2011</td><td>anonymous</td><td>1.2 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>anonymous</td><td>12.1347 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>anonymous</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>anonymous</td><td>5 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>anonymous</td><td>5 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>uglic</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>vention</td><td>73 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>anonymous</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Oct, 2011</td><td>4get</td><td></td><td>163 &euro;</td><td>RU translation delayed payment</td></tr>
<tr><td>Nov, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Nov, 2011</td><td>anonymous</td><td>10 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Nov, 2011</td><td>Daniel Liabeuf</td><td>20 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Nov, 2011</td><td>anonymous</td><td>15 &euro;</td><td></td><td>Bounty eepsites in datastorage</td></tr>
<tr><td>Nov, 2011</td><td>maxkoda</td><td>5.23 BTC</td><td></td><td>bounty BTC client in I2P</td></tr>
<tr><td>Nov, 2011</td><td>anonymous</td><td>0.512 BTC</td><td></td><td>General fund</td></tr>
<tr><td>Dec, 2011</td><td>anonymous</td><td>30 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Dec, 2011</td><td>silc bounty</td><td>100 &euro;</td><td></td><td>ReturningNovice</td></tr>
<tr><td>Dec, 2011</td><td>silc bounty</td><td>100 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Dec, 2011</td><td>ReturningNovice</td><td>50 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Dec, 2011</td><td>ReturningNovice</td><td>50 &euro;</td><td></td><td>Sponge</td></tr>
<tr><td>Dec, 2011</td><td>anonymous</td><td>5 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Dec, 2011</td><td>anonymous</td><td>5 &euro;</td><td></td><td>General fund</td></tr>
<tr><td>Dec, 2011</td><td>maxkoda</td><td>5.01 BTC</td><td></td><td>bounty BTC client in I2P</td></tr>
<tr><td>Dec, 2011</td><td>anonymous</td><td>0.4825475 BTC</td><td></td><td>Sponge</td></tr>
<tr><td>Dec, 2011</td><td>anonymous</td><td>5,54436182 BTC</td><td></td><td>general fund</td></tr>
<tr><td>Dec, 2011</td><td>PayPal</td><td></td><td>100 &euro;</td><td>PayPal fees 2011</td></tr>
</table>
<br />
<br />
<b>Previous to 2011 donations:</b><br />
<table border="1">
<tr><td>Dec, 2010</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Dec, 2010</td><td>anonymous</td><td>30 &euro;</td><td>General fund</td></tr>
<tr><td>Dec, 2010</td><td>anonymous</td><td>$20 USD</td><td>General fund</td></tr>
<tr><td>Dec, 2010</td><td>anonymous</td><td>$10 USD</td><td>General fund</td></tr>
<tr><td>Dec, 2010</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Dec, 2010</td><td>anonymous</td><td>1.50 &euro;</td><td>General fund</td></tr>
<tr><td>Dec, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Nov, 2010</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Oct, 2010</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Oct, 2010</td><td>anonymous</td><td>15 &euro;</td><td>General fund</td></tr>
<tr><td>Oct, 2010</td><td>ru bounty payback</td><td>$230 USD</td><td>General fund</td></tr>
<tr><td>Oct, 2010</td><td>R.Schwabe</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Oct, 2010</td><td>Flattr</td><td>29,40 &euro;</td><td>General fund</td></tr>
<tr><td>Sep, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Sep, 2010</td><td>anonymous</td><td>11 &euro;</td><td>General fund</td></tr>
<tr><td>Sep, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Sep, 2010</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Sep, 2010</td><td>R.Schwabe</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Sep, 2010</td><td>anonymous</td><td>15 &euro;</td><td>General fund</td></tr>
<tr><td>Aug, 2010</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Aug, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Jul, 2010</td><td>anonymous</td><td>6,50 PLN</td><td>General fund</td></tr>
<tr><td>Jul, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Jul, 2010</td><td>anonymous</td><td>5 &euro;</td><td>General fund</td></tr>
<tr><td>Jul, 2010</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Jul, 2010</td><td>anonymous</td><td>30 &euro;</td><td>General fund</td></tr>
<tr><td>Jun, 2010</td><td>anonymous</td><td>5 &euro;</td><td>General fund</td></tr>
<tr><td>Jun, 2010</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Jun, 2010</td><td>anonymous</td><td>8 &euro;</td><td>General fund</td></tr>
<tr><td>Jun, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>May, 2010</td><td>anonymous</td><td>$ 20 CAD</td><td>General fund</td></tr>
<tr><td>May, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>May, 2010</td><td>anonymous</td><td>7 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2010</td><td>anonymous</td><td>&pound; 60 SCO</td><td>General fund</td></tr>
<tr><td>Apr, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2010</td><td>anonymous</td><td>200 &euro;</td><td>Datastorage bounty</td></tr>
<tr><td>Apr, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2010</td><td>Mozartito</td><td>5 &euro;</td><td>General fund</td></tr>
<tr><td>Mar, 2010</td><td>anonymous</td><td>140 &euro;</td><td>General fund</td></tr>
<tr><td>Mar, 2010</td><td>anonymous</td><td>10 &euro;</td><td>Abo General fund</td></tr>
<tr><td>Mar, 2010</td><td>anonymous</td><td>10 &euro;</td><td>Abo General fund</td></tr>
<tr><td>Feb, 2010</td><td>anonymous</td><td>10 &euro;</td><td>Abo General fund</td></tr>
<tr><td>Feb, 2010</td><td>anonymous</td><td>5 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>500 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>bernerbaer</td><td>50 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>15 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2009-Jan, 2010</td><td>neutron</td><td>20 &euro;/month</td><td>outproxy fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>$20 USD</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>6.80 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Dec, 2009</td><td>anonymous</td><td>5 &euro;</td><td>General fund</td></tr>
<tr><td>Dec, 2009</td><td>anonymous</td><td>35 &euro;</td><td>General fund</td></tr>
<tr><td>Nov, 2009</td><td>russian donor</td><td>230 $</td><td>Russian translation bounty</td></tr>
<tr><td>Nov, 2009</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Oct, 2009</td><td>echelon</td><td>10 &euro;</td><td>i2phex bounty</td></tr>
<tr><td>Oct, 2009</td><td>arne bab</td><td>10 &euro;</td><td>i2phex bounty</td></tr>
<tr><td>Oct, 2009</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Aug, 2009</td><td>anonymous</td><td>400 &euro;</td><td>General fund</td></tr>
<tr><td>Aug, 2009</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Aug, 2009</td><td>anonymous</td><td>100 &euro;</td><td>General fund</td></tr>
<tr><td>Jul, 2009</td><td>G.Klaus</td><td>15 &euro;</td><td>General fund</td></tr>
<tr><td>Jul, 2009</td><td>R.Schwabe</td><td>$20 USD</td><td>General fund</td></tr>
<tr><td>Jun, 2009</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Jun, 2009</td><td>Cendre</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Jun, 2009</td><td>M.Hilbig</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Jun, 2009</td><td>anonymous</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>May, 2009</td><td>EoL</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2009</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2009</td><td>anonymous</td><td>60 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2009</td><td>Gilgongo</td><td>15 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2009</td><td>Amiga4000</td><td>50 &euro;</td><td>I2P vuze plugin bounty</td></tr>
<tr><td>Mar, 2009</td><td>[anonymous]</td><td>50 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2009</td><td>[anonymous]</td><td>30 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2009</td><td>DVT</td><td>20 &euro;</td><td>General fund</td></tr>
<tr><td>Oct, 2008</td><td>eche|on</td><td>500.0 &euro;</td><td>Datastorage bounty</td></tr>
<tr><td>Mar, 2007</td><td>zzz</td><td>$200 USD</td><td>General fund</td></tr>
<tr><td>Nov, 2006-Dec, 2007</td><td>[anonymous]</td><td>$10 USD/month</td><td>general fund</td></tr>
<tr><td>Dec, 2006</td><td>bar</td><td colspan="2">New mac testing machine</td></tr>
<tr><td>Dec, 2006</td><td>[anonymous]</td><td>$200 USD</td><td>General fund</td></tr>
<tr><td>Oct, 2006</td><td>[anonymous]</td><td>$150 USD</td><td>General fund</td></tr>
<tr><td>Oct, 2006</td><td>[anonymous]</td><td>$100 USD</td><td>General fund</td></tr>
<tr><td>Oct, 2005-Oct, 2006</td><td>Eol</td><td>$10 USD/month</td><td>General fund</td></tr>
<tr><td>Oct, 2006</td><td>Peter</td><td>$750 USD</td><td>General fund</td></tr>
<tr><td>Jun, 2006</td><td>[anonymous]</td><td>$450 USD</td><td>General fund</td></tr>
<tr><td>Jun, 2006</td><td>[anonymous]</td><td>$10 USD</td><td>General fund</td></tr>
<tr><td>Jun, 2006</td><td>[anonymous]</td><td>$10 USD</td><td>General fund</td></tr>
<tr><td>May, 2006</td><td>athena</td><td>$135 USD</td><td>General fund</td></tr>
<tr><td>Apr, 2006</td><td>postman</td><td>$300 USD</td><td>General fund</td></tr>
<tr><td>Apr, 2006</td><td>[anonymous]</td><td>$300 USD</td><td>General fund</td></tr>
<tr><td>Apr, 2006</td><td>[anonymous]</td><td>$500 USD</td><td>General fund</td></tr>
<tr><td>Apr, 2006</td><td>[anonymous]</td><td>$100 USD</td><td>General fund</td></tr>
<tr><td>Apr, 2006</td><td>[anonymous]</td><td>$10 USD</td><td>General fund</td></tr>
<tr><td>Apr, 2006</td><td>[anonymous]</td><td>$50 USD</td><td>General fund</td></tr>
<tr><td>Apr, 2006</td><td>[anonymous]</td><td>$15 USD</td><td>General fund</td></tr>
<tr><td>Apr, 2006</td><td>[anonymous]</td><td>$12 USD</td><td>General fund</td></tr>
<tr><td>Mar, 2006</td><td>[anonymous]</td><td>$30 USD</td><td>General fund</td></tr>
<tr><td>Mar, 2006</td><td>[anonymous]</td><td>$800 USD</td><td>General fund</td></tr>
<tr><td>Mar, 2006</td><td>bar</td><td colspan="2">New development machine</td></tr>
<tr><td>Mar, 2006</td><td>postman</td><td>$300 USD</td><td>General fund</td></tr>
<tr><td>Mar, 2006</td><td>[anonymous]</td><td>$5 USD</td><td>General fund</td></tr>
<tr><td>Feb, 2006</td><td>[anonymous]</td><td>$50 USD</td><td>General fund</td></tr>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$500 USD</td><td>Unit test bounty</td></tr>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$25 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$40 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$50 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$20 USD</td><td>I2P general fund</td></tr>
<tr><td>Dec, 2005</td><td>[anonymous]</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Dec, 2005</td><td>[anonymous]</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2005-Dec, 2007</td><td>[anonymous]</td><td>$10 USD/month</td><td>general fund</td></tr>
<tr><td>Nov, 2005-Dec, 2007</td><td>[anonymous]</td><td>$50 USD/month</td><td>general fund</td></tr>
<tr><td>Nov, 2005</td><td>aum</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2005</td><td>aum</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2005</td><td>[anonymous]</td><td>$50 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2005</td><td>[anonymous]</td><td>$100 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2005</td><td>Aurimas Fiseras</td><td>$20 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2005</td><td>[anonymous]</td><td>$500 USD</td><td>I2P general fund</td></tr>
<tr><td>Oct, 2005-Dec, 2007</td><td>[anonymous]</td><td>$200 USD/month</td><td>general fund</td></tr>
<tr><td>Oct, 2005</td><td>Doubtful salmon</td><td>$120 USD</td><td>Bundling bounties</td></tr>
<tr><td>Oct, 2005</td><td>[anonymous]</td><td>$1000 USD</td><td>I2P general fund</td></tr>
<tr><td>Sep, 2005</td><td>[anonymous]</td><td>$25 USD</td><td>GCJ bounty</td></tr>
<tr><td>Sep, 2005</td><td>[anonymous]</td><td>$25 USD</td><td>I2P general fund</td></tr>
<tr><td>Jul, 2005</td><td>Anthony Skipper</td><td>$50 USD</td><td>I2P general fund</td></tr>
<tr><td>Jul, 2005</td><td>Chris Wong</td><td>$50 USD</td><td>I2P general fund</td></tr>
<tr><td>Jun-Nov, 2005</td><td>[anonymous]</td><td>$60 USD</td><td>I2P general fund</td></tr>
<tr><td>Jun, 2005</td><td>[anonymous]</td><td>$3 USD</td><td>I2P general fund</td></tr>
<tr><td>May, 2005</td><td>Timothy Wesson</td><td>$60 USD</td><td>I2P general fund</td></tr>
<tr><td>Apr, 2005</td><td>Zlatin Balevsky</td><td>$500 USD</td><td>Unit test bounty</td></tr>
<tr><td>Apr, 2005</td><td>Dale Jefferson</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Mar, 2005</td><td>Synonymous</td><td>$3.45 USD</td><td>I2P general fund</td></tr>
<tr><td>Mar, 2005-Sep, 2005</td><td>David Hjelm</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Feb, 2005</td><td>Marcus Felker</td><td>$20 USD</td><td>I2P general fund</td></tr>
<tr><td>Feb-Dec, 2005</td><td>Sebastian Spaeth</td><td>$200 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2005-Dec, 2007</td><td>[anonymous]</td><td>$10 USD/month</td><td>general fund</td></tr>
<tr><td>Jan, 2005-Jun, 2005</td><td>Martin Stares</td><td>$60 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2005</td><td>Nico Zimmerman</td><td>$2 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2004-Dec, 2007</td><td>jnymo</td><td>$10 USD/month</td><td>general fund</td></tr>
<tr><td>Dec, 2004, May, 2005</td><td>Elliot Turner</td><td>$350 USD</td><td>I2P general fund</td></tr>
<tr><td>Dec, 2004</td><td>[anonymous]</td><td>$5 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2004</td><td>modulus</td><td>$40 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2004</td><td>Salvador Petit</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2004</td><td>Philip Bock</td><td>$100 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2004</td><td>cervantes</td><td>$154 USD</td><td>I2P general fund</td></tr>
<tr><td>Sep, 2004</td><td>[anonymous]</td><td>$20 USD</td><td>I2P general fund</td></tr>
<tr><td>Sep, 2004</td><td>[anonymous]</td><td>$400 USD</td><td>I2P general fund</td></tr>
<tr><td>Aug, 2004-Apr, 2005</td><td>nickster</td><td>$90 USD</td><td>I2P general fund</td></tr>
<tr><td>May, 2004</td><td>protokol</td><td>$2.24 USD</td><td>I2P general fund</td></tr>
<tr><td>May, 2004-Sep, 2005</td><td>Jeff Teitel</td><td>$135 USD</td><td>I2P general fund</td></tr>
<tr><td>Apr, 2004-Dec, 2004</td><td>eco</td><td>$150 USD</td><td>I2P general fund, GCJ bounty</td></tr>
<tr><td>Apr, 2004</td><td>wilde</td><td>$60 USD</td><td>MyI2P bounty</td></tr>
<tr><td>Mar, 2004</td><td>bla</td><td>$15 USD</td><td>I2P general fund</td></tr>
<tr><td>Mar, 2004-Apr, 2005</td><td>duck</td><td>$720 USD</td><td>Unit test and other bounties</td></tr>
</table>
{% endblock %}

52
i2p2www/pages/site/volunteer/index.html Normal file
View File

@@ -0,0 +1,52 @@
{% extends "global/layout.html" %}
{% block title %}Get Involved!{% endblock %}
{% block content %}
<h1>We need your help!</h1>
<p>To get involved, please feel free to join us on the #i2p IRC channel (on
irc.freenode.net, or within I2P on irc.freshcoffee.i2p or irc.postman.i2p).</p>
<p>If you're interested in joining our <a href="team">team</a>, please get in
touch as we're always looking for eager contributors!</p>
<p>
We need help in many areas, and you don't need to know Java to contribute!
Here's a list to help you get started!</p>
<ul>
<li><b>Spread the Word!</b> &mdash;
Tell people about I2P on forums, blogs, and comments to articles.
Fix up the Wikipedia article about I2P in your language.
Tell your friends.
</li><li><b>Testing</b> &mdash;
Run the latest builds from <a href="monotone.html">monotone</a>
and report results on #i2p or as bugs on <a href="http://trac.i2p2.de/report/1">Trac</a>.
</li><li><b>Documentation</b> &mdash;
Help fix the parts of the website that are outdated or incomplete.
Translate pages into other languages.
</li><li><b>Pictures</b> &mdash;
Make some more pictures, fix the old ones on the website
</li><li><b>Content</b> &mdash;
Make an eepsite! Add some content! Contribute to the community!
</li><li><b>Services</b> &mdash;
Run a service on an eepsite. It could be a proxy, a forum, a tracker,
a naming service, a search engine, an eepsite monitor... many of these
aren't that hard.
</li><li><b>Applications</b> &mdash;
Write or port applications for I2P! There's some guidelines and
a list of ideas on the <a href="applications.html">applications page</a>.
</li><li><b>Coding</b> &mdash;
There's plenty to do if you know Java or are ready to learn.
Check for open tickets on <a href="http://trac.i2p2.de/report/1">Trac</a>
or the TODO list on <a href="http://zzz.i2p/">zzz.i2p</a> for
some ideas on where to start.
See the <a href="newdevelopers.html">new developer's guide</a> for details.
</li><li><b>Translation</b> &mdash;
Help translate the website and the software into your language.
See the <a href="newtranslators.html">new translator's guide</a> for details.
</li><li><b>Analysis</b> &mdash;
Study or test the code to look for vulnerabilities.
Both anonymity vulnerabilities from the various
<a href="{{ site_url('docs/how/threatmodel') }}">threat models</a>,
and DOS and other weaknesses due to securities holes,
need researching.
</li><li><b><a href="donate.html">Donate</a></b>
</li></ul>
{% endblock %}

34
i2p2www/pages/site/volunteer/roadmap.html Normal file
View File

@@ -0,0 +1,34 @@
{% extends "global/layout.html" %}
{% block title %}Roadmap{% endblock %}
{% block content %}
<h2 id="v0.9">0.9</h2>
<ul>
<li>Include some seed data in the distribution so a central reseed location isn't required?</li>
<li>Reachability Mapping / handle peers partially reachable / enhanced <a href="{{ site_url('volunteer/todo') }}#fullRestrictedRoutes">restricted routes</a></li>
<li>Improve help pages and website</li>
<li>More translations</li>
<li>SSU disconnect message</li>
<li>Iterative floodfill lookups</li>
</ul>
<h2 id="v1.0">1.0</h2>
<ul>
<li>Full review of anonymity issues and other vulnerabilities</li>
<li>Reduce memory usage, remove debugging overhead, make it run better on slow and embedded machines</li>
<li>Docs</li>
</ul>
<h2 id="v2.0">2.0</h2>
<ul>
<li>Full restricted routes</li>
</ul>
<h2 id="v3.0">3.0</h2>
<ul>
<li>Tunnel mixing and padding</li>
<li>User defined message delays</li>
</ul>
<p>Please see the <a href="{{ site_url('volunteer/todo') }}">TODO</a> list for more detailed info about some of these tasks.</p>
{% endblock %}