320 lines
14 KiB
HTML
320 lines
14 KiB
HTML
{% extends "global/layout.html" %}
|
|
{% block title %}{% trans %}Garlic Routing{% endtrans %}{% endblock %}
|
|
{% block lastupdated %}{% trans %}March 2014{% endtrans %}{% endblock %}
|
|
{% block accuratefor %}0.9.12{% endblock %}
|
|
{% block content %}
|
|
<h2>{% trans %}Garlic Routing and "Garlic" Terminology{% endtrans %}</h2>
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
"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://www.onion-router.net/">Onion Routing</a>.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
"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:
|
|
{%- endtrans %}</p>
|
|
<ol>
|
|
<li>{% trans %}Layered Encryption{% endtrans %}</li>
|
|
<li>{% trans %}Bundling multiple messages together{% endtrans %}</li>
|
|
<li>{% trans %}ElGamal/AES Encryption{% endtrans %}</li>
|
|
</ol>
|
|
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
<h3>{% trans %}Layered Encryption{% endtrans %}</h3>
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans comparisons=site_url('comparison') -%}
|
|
This is similar to the way Mixmaster
|
|
(see <a href="{{ comparisons }}">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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
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>.
|
|
{%- endtrans %}</p>
|
|
|
|
|
|
<h3>{% trans %}Bundling Multiple Messages{% endtrans %}</h3>
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
|
|
<h3>{% trans %}ElGamal/AES Encryption{% endtrans %}</h3>
|
|
<p>{% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
|
|
In some cases, "garlic encryption" may simply mean
|
|
<a href="{{ elgamalaes }}">ElGamal/AES+SessionTag</a> encryption
|
|
(without multiple layers).
|
|
{%- endtrans %}</p>
|
|
|
|
|
|
|
|
<h2>{% trans %}"Garlic" Methods in I2P{% endtrans %}</h2>
|
|
<p>{% trans -%}
|
|
Now that we've defined various "garlic" terms, we can say that
|
|
I2P uses garlic routing, bundling and encryption in three places:
|
|
{%- endtrans %}</p>
|
|
<ol>
|
|
<li>{% trans %}For building and routing through tunnels (layered encryption){% endtrans %}
|
|
<li>{% trans %}For determining the success or failure of end to end message delivery (bundling){% endtrans %}
|
|
<li>{% trans %}For publishing some network database entries (dampening the probability of a successful traffic analysis attack) (ElGamal/AES){% endtrans %}
|
|
</ol>
|
|
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
|
|
<h3>{% trans %}Tunnel Building and Routing{% endtrans %}</h3>
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans tunnelimpl=site_url('docs/tunnels/implementation'),
|
|
tunnelcreation=site_url('docs/spec/tunnel-creation'),
|
|
elgamalaes=site_url('docs/how/elgamal-aes') -%}
|
|
Tunnels are built, and then used, with layered encryption.
|
|
This is described on the
|
|
<a href="{{ tunnelimpl }}">tunnel implementation page</a>.
|
|
Tunnel building details are defined on
|
|
<a href="{{ tunnelcreation }}">this page</a>.
|
|
We use
|
|
<a href="{{ elgamalaes }}">ElGamal/AES+SessionTag</a> for the encryption.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans i2np=site_url('docs/protocol/i2np'), i2npspec=site_url('docs/spec/i2np') -%}
|
|
Tunnels are a general-purpose mechanism to transport all
|
|
<a href="{{ i2np }}">I2NP messages</a>, and
|
|
<a href="{{ i2npspec }}#msg_Garlic">Garlic Messages</a> are not used to build tunnels.
|
|
We do not bundle multiple
|
|
<a href="{{ i2np }}">I2NP messages</a> into a single
|
|
<a href="{{ i2npspec }}#msg_Garlic">Garlic Message</a> for unwrapping at the outbound tunnel endpoint;
|
|
the tunnel encryption is sufficient.
|
|
{%- endtrans %}</p>
|
|
|
|
|
|
<h3>{% trans %}End-to-End Message Bundling{% endtrans %}</h3>
|
|
<p>{% trans commonstructures=site_url('docs/spec/common-structures'),
|
|
elgamalaes=site_url('docs/how/elgamal-aes'),
|
|
i2cp=site_url('docs/protocol/i2cp'),
|
|
i2npspec=site_url('docs/spec/i2np') -%}
|
|
At the layer above tunnels, I2P delivers end-to-end messages between
|
|
<a href="{{ commonstructures }}#struct_Destination">Destinations</a>.
|
|
Just as within a single tunnel, we use
|
|
<a href="{{ elgamalaes }}">ElGamal/AES+SessionTag</a> for the encryption.
|
|
Each client message as delivered to the router through the
|
|
<a href="{{ i2cp }}">I2CP interface</a> becomes a single
|
|
<a href="{{ i2npspec }}#struct_GarlicClove">Garlic Clove</a>
|
|
with its own
|
|
<a href="{{ i2npspec }}#struct_GarlicCloveDeliveryInstructions">Delivery Instructions</a>,
|
|
inside a
|
|
<a href="{{ i2npspec }}#msg_Garlic">Garlic Message</a>.
|
|
Delivery Instructions may specify a Destination, Router, or Tunnel.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
Generally, a Garlic Message will contain only one clove.
|
|
However, the router will periodically bundle two additional
|
|
cloves in the Garlic Message:
|
|
{%- endtrans %}</p>
|
|
<img src="/_static/images/garliccloves.png" alt="{{ _('Garlic Message Cloves') }}" title="{{ _('Garlic Message Cloves') }}" style="text-align:center;"/>
|
|
|
|
<ol>
|
|
<li>{% trans i2npspec=site_url('docs/spec/i2np') -%}
|
|
A
|
|
<a href="{{ i2npspec }}#msg_DeliveryStatus">Delivery Status Message</a>,
|
|
with
|
|
<a href="{{ i2npspec }}#struct_GarlicCloveDeliveryInstructions">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.
|
|
{%- endtrans %}</li>
|
|
<li>{% trans i2npspec=site_url('docs/spec/i2np'),
|
|
commonstructures=site_url('docs/spec/common-structures'),
|
|
netdb=site_url('docs/how/network-database') -%}
|
|
A
|
|
<a href="{{ i2npspec }}#msg_DatabaseStore">Database Store Message</a>,
|
|
containing a
|
|
<a href="{{ commonstructures }}#struct_LeaseSet">LeaseSet</a>
|
|
for the originating Destination, with
|
|
<a href="{{ i2npspec }}#struct_GarlicCloveDeliveryInstructions">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="{{ netdb }}">network database page</a>.
|
|
{%- endtrans %}</li>
|
|
</ol>
|
|
|
|
<p>{% trans commonstructures=site_url('docs/spec/common-structures'),
|
|
i2cp=site_url('docs/protocol/i2cp'),
|
|
i2cpspec=site_url('docs/spec/i2cp') -%}
|
|
By default, the Delivery Status and Database Store Messages
|
|
are bundled when the local LeaseSet changes, when additional
|
|
<a href="{{ commonstructures }}#type_SessionTag">Session Tags</a>
|
|
are delivered, or if the messages have not been bundled in the previous minute.
|
|
As of release 0.9.2, the client may configure the default number of Session Tags to send
|
|
and the low tag threshold for the current session.
|
|
See the <a href="{{ i2cp }}#options">I2CP options specification</a> for details.
|
|
The session settings may also be overridden on a per-message basis.
|
|
See the <a href="{{ i2cpspec }}#msg_SendMessageExpires">I2CP Send Message Expires specification</a> for details.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
Obviously, the additional messages are currently bundled for specific purposes,
|
|
and not part of a general-purpose routing scheme.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
As of release 0.9.12, the Delivery Status Message is wrapped in another Garlic Message
|
|
by the originator so that the contents are encrypted and not visible to routers on the return path.
|
|
{%- endtrans %}</p>
|
|
|
|
|
|
<h3>{% trans %}Storage to the Floodfill Network Database{% endtrans %}</h3>
|
|
<p>{% trans netdb=site_url('docs/how/network-database'),
|
|
commonstructures=site_url('docs/spec/common-structures'),
|
|
i2npspec=site_url('docs/spec/i2np') -%}
|
|
As explained on the
|
|
<a href="{{ netdb }}#delivery">network database page</a>,
|
|
local
|
|
<a href="{{ commonstructures }}#struct_LeaseSet">LeaseSets</a>
|
|
are sent to floodfill routers in a
|
|
<a href="{{ i2npspec }}#msg_DatabaseStore">Database Store Message</a>
|
|
wrapped in a
|
|
<a href="{{ i2npspec }}#msg_Garlic">Garlic Message</a>
|
|
so it is not visible to the tunnel's outbound gateway.
|
|
{%- endtrans %}</p>
|
|
|
|
|
|
<h2>{% trans %}Future Work{% endtrans %}</h2>
|
|
<p>{% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%}
|
|
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="{{ tunnelmessage }}#struct_TunnelMessageDeliveryInstructions">tunnel message Delivery Instructions</a>,
|
|
a wide spectrum of batching, delay, mixing, and routing strategies are possible.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans elgamalaes=site_url('docs/how/elgamal-aes') -%}
|
|
As a part of
|
|
<a href="{{ 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.
|
|
{%- endtrans %}</p>
|
|
|
|
<p>{% trans netdb=site_url('docs/how/network-database') -%}
|
|
Encryption of additional messages to and from the
|
|
<a href="{{ netdb }}#delivery">floodfill routers</a>.
|
|
{%- endtrans %}</p>
|
|
|
|
|
|
|
|
|
|
<h2>{% trans %}References{% endtrans %}</h2>
|
|
<ul>
|
|
<li>{% trans -%}
|
|
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>.
|
|
{%- endtrans %}</li>
|
|
<li>
|
|
<a href="http://www.onion-router.net/Publications.html">{% trans %}Onion router publications{% endtrans %}</a>
|
|
</li><li>
|
|
<a href="http://en.wikipedia.org/wiki/Onion_routing">{% trans %}Onion Routing on Wikipedia{% endtrans %}</a>
|
|
</li><li>
|
|
<a href="http://en.wikipedia.org/wiki/Garlic_routing">{% trans %}Garlic Routing on Wikipedia{% endtrans %}</a>
|
|
</li>
|
|
<li>{% trans meeting58=get_url('meetings_show', id=58) -%}
|
|
<a href="{{ meeting58 }}">I2P Meeting 58</a> (2003) discussing the implementation of garlic routing
|
|
{%- endtrans %}</li>
|
|
<li>
|
|
<a href="https://www.torproject.org/">Tor</a>
|
|
</li><li>
|
|
<a href="http://freehaven.net/anonbib/topic.html">{% trans %}Free Haven publications{% endtrans %}</a>
|
|
</li>
|
|
<li>{% trans -%}
|
|
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.
|
|
{%- endtrans %}</li>
|
|
</ul>
|
|
|
|
{% endblock %}
|