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

More URL fixes

Browse Source
This commit is contained in:
str4d
2013-02-06 04:03:51 +00:00
parent 88c773cc4a
commit 8281464f73
6 changed files with 61 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
i2p2www/pages/site/docs/discussions/tunnel.html
View File

@ -5,12 +5,12 @@
Note: This document contains older information about alternatives to the
current tunnel implementation in I2P,
and speculation on future possibilities. For current information see
<a href="tunnel-alt.html">the tunnel page</a>.
<a href="{{ site_url('docs/tunnels/implementation') }}">the tunnel page</a>.
<p>
That page documents the current tunnel build implementation as of release 0.6.1.10.
The older tunnel build method, used prior to release 0.6.1.10, is documented on
<a href="tunnel.html">the old tunnel page</a>.
<a href="{{ site_url('docs/tunnels/old-implementation') }}">the old tunnel page</a>.
<h3 id="config">Configuration Alternatives</h3>
<p>Beyond their length, there may be additional configurable parameters
@ -150,7 +150,7 @@ Reference:
<h4 id="tunnel.building.old">Old tunnel build method</h4>
The old tunnel build method, used prior to release 0.6.1.10, is documented on
<a href="tunnel.html">the old tunnel page</a>.
<a href="{{ site_url('docs/tunnels/old-implementation') }}">the old tunnel page</a>.
This was an "all at once" or "parallel" method,
where messages were sent in parallel to each of the participants.
@ -213,9 +213,9 @@ Sponge has proposed using 'tokens' of some sort.
<p>
Any students of tunnel building must study the historical record leading up to the current method,
especially the various anonymity vulnerabilities that may exist in various methods.
The mail archives from October 2005 at <a href="http://zzz.i2p/archives/2005-10/">zzz.i2p</a> or
The mail archives from October 2005 at <a href="http://{{ i2pconv('zzz.i2p') }}/archives/2005-10/">zzz.i2p</a> or
<a href="http://osdir.com/ml/network.i2p/2005-10/">osdir.com</a> are particularly helpful.
As stated on <a href="tunnel-alt-creation.html">the tunnel creation specification</a>,
As stated on <a href="{{ site_url('docs/spec/tunnel-creation') }}">the tunnel creation specification</a>,
the current strategy came about during a discussion on the I2P mailing list between
Michael Rogers, Matthew Toseland (toad), and jrandom regarding the predecessor attack.
See:<a href="http://osdir.com/ml/network.i2p/2005-10/msg00138.html">Summary</a> and
@ -240,6 +240,6 @@ reordering, rerouting, or padding messages? To what extent should this be done
automatically, how much should be configured as a per tunnel or per hop setting,
and how should the tunnel's creator (and in turn, user) control this operation?
All of this is left as unknown, to be worked out for
<a href="http://www.i2p.net/roadmap#3.0">I2P 3.0</a></p>
<a href="{{ site_url('get-involved/roadmap') }}#v3.0">I2P 3.0</a></p>
{% endblock %}

40
i2p2www/pages/site/docs/spec/i2np.html
View File

@ -23,11 +23,11 @@ They are not complete messages.
</p>
<h4>Contents</h4>
<p>
1 byte <a href="{{ site_url('docs/spec/common_structures') }}#type_Integer">Integer</a> specifying the type of this message,
followed by a 4 byte <a href="{{ site_url('docs/spec/common_structures') }}#type_Integer">Integer</a> specifying the message-id.
After that there is an expiration <a href="{{ site_url('docs/spec/common_structures') }}#type_Date">Date</a>,
followed by a 2 byte <a href="{{ site_url('docs/spec/common_structures') }}#type_Integer">Integer</a> specifying
the length of the message payload, followed by a <a href="{{ site_url('docs/spec/common_structures') }}#type_Hash">Hash</a>,
1 byte <a href="{{ site_url('docs/spec/common-structures') }}#type_Integer">Integer</a> specifying the type of this message,
followed by a 4 byte <a href="{{ site_url('docs/spec/common-structures') }}#type_Integer">Integer</a> specifying the message-id.
After that there is an expiration <a href="{{ site_url('docs/spec/common-structures') }}#type_Date">Date</a>,
followed by a 2 byte <a href="{{ site_url('docs/spec/common-structures') }}#type_Integer">Integer</a> specifying
the length of the message payload, followed by a <a href="{{ site_url('docs/spec/common-structures') }}#type_Hash">Hash</a>,
which is truncated to the first byte. After that the actual message data follows.
</p>
<pre>
@ -110,12 +110,12 @@ where the far-end router's version is known and checksum generation can be disab
<h4>Description</h4>
<p>
One Record in a set of multiple records to request the creation of one hop in the tunnel. For more details see
<a href="tunnel-alt.html">the tunnel overview</a> and
<a href="tunnel-alt-creation.html">the tunnel creation specification</a>.
<a href="{{ site_url('docs/tunnels/implementation') }}">the tunnel overview</a> and
<a href="{{ site_url('docs/spec/tunnel-creation') }}">the tunnel creation specification</a>.
</p>
<h4>Contents</h4>
<p>
<a href="{{ site_url('docs/spec/common_structures') }}#type_TunnelId">TunnelId</a> to receive messages on, followed by the <a href="{{ site_url('docs/spec/common_structures') }}#type_Hash">Hash</a> of our <a href="{{ site_url('docs/spec/common_structures') }}#struct_RouterIdentity">RouterIdentity</a>. After that the <a href="{{ site_url('docs/spec/common_structures') }}#type_TunnelId">TunnelId</a> and the <a href="{{ site_url('docs/spec/common_structures') }}#type_Hash">Hash</a> of the next router's <a href="{{ site_url('docs/spec/common_structures') }}#struct_RouterIdentity">RouterIdentity</a> follow.
<a href="{{ site_url('docs/spec/common-structures') }}#type_TunnelId">TunnelId</a> to receive messages on, followed by the <a href="{{ site_url('docs/spec/common-structures') }}#type_Hash">Hash</a> of our <a href="{{ site_url('docs/spec/common-structures') }}#struct_RouterIdentity">RouterIdentity</a>. After that the <a href="{{ site_url('docs/spec/common-structures') }}#type_TunnelId">TunnelId</a> and the <a href="{{ site_url('docs/spec/common-structures') }}#type_Hash">Hash</a> of the next router's <a href="{{ site_url('docs/spec/common-structures') }}#struct_RouterIdentity">RouterIdentity</a> follow.
</p>
<h4>Definition</h4>
<pre>
@ -274,7 +274,7 @@ the ElGamal data contains bytes 1-256 and 258-513 of the
<a href="{{ site_url('docs/how/cryptography') }}#elgamal">514-byte ElGamal encrypted block</a>.
The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed.
</li><li>
See the <a href="tunnel-alt-creation.html">tunnel creation specification</a> for details on field contents.
See the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a> for details on field contents.
</li></ul>
</p>
@ -312,7 +312,7 @@ total length: 528
The first 527 bytes could, in the future, be used to return congestion or peer connectivity information
back to the requestor.
</li><li>
See the <a href="tunnel-alt-creation.html">tunnel creation specification</a> for details on the reply field.
See the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a> for details on the reply field.
</li></ul>
@ -380,7 +380,7 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
<h3 id="struct_DeliveryInstructions">Delivery Instructions</h3>
Defined in the <a href="tunnel_message_spec.html#delivery">Tunnel Message Specification</a>.
Defined in the <a href="{{ site_url('docs/spec/tunnel-message') }}#delivery">Tunnel Message Specification</a>.
<h2 id="messages">Messages</h2>
@ -508,7 +508,7 @@ reply token:
reply tunnelId:
4 byte Tunnel ID
only included if reply token &gt; 0
This is the <a href="{{ site_url('docs/spec/common_structures') }}#type_TunnelID">tunnel ID</a> of the inbound gateway of the tunnel the response should be sent to
This is the <a href="{{ site_url('docs/spec/common-structures') }}#type_TunnelID">tunnel ID</a> of the inbound gateway of the tunnel the response should be sent to
reply gateway:
32 bytes
@ -801,11 +801,11 @@ Expiration :: Date (8 bytes)
the minimum size of the encrypted message is 160 bytes; with the 4 length bytes
the minimum size of the Garlic Message is 164 bytes.
<li>
Actual max length is less than 64 KB; see the <a href="i2np.html">I2NP Overview</a>.
Actual max length is less than 64 KB; see the <a href="{{ site_url('docs/protocol/i2np') }}">I2NP Overview</a>.
<li>
See also the <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES specification</a>.
See also the <a href="{{ site_url('docs/how/elgamal-aes') }}">ElGamal/AES specification</a>.
<li>
See also the <a href="{{ site_url('docs/how/garlicrouting') }}">garlic routing specification</a>.
See also the <a href="{{ site_url('docs/how/garlic-routing') }}">garlic routing specification</a>.
<li>
The 128 byte minimum size of the AES encrypted block is not currently configurable,
however the minimum size of a DataMessage in a GarlicClove in a GarlicMessage, with
@ -851,7 +851,7 @@ data:
<h4>Notes</h4>
<ul>
<li>
See also the <a href="{{ site_url('docs/spec/tunnel_message') }}">Tunnel Message Specification</a>
See also the <a href="{{ site_url('docs/spec/tunnel-message') }}">Tunnel Message Specification</a>
</ul>
@ -949,7 +949,7 @@ Total size: 8*528 = 4224 bytes
<h4>Notes</h4>
<p>
See also the <a href="tunnel-alt-creation.html">tunnel creation specification</a>.
See also the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a>.
</p>
@ -962,7 +962,7 @@ same format as TunnelBuild message, with Build Response Records
<h4>Notes</h4>
<p>
See also the <a href="tunnel-alt-creation.html">tunnel creation specification</a>.
See also the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a>.
</p>
<h3 id="msg_VariableTunnelBuild">VariableTunnelBuild</h3>
@ -993,7 +993,7 @@ Total size: 1 + $num*528
<li>
This message was introduced in router version 0.7.12, and may not be sent to tunnel participants earlier than that version.
<li>
See also the <a href="tunnel-alt-creation.html">tunnel creation specification</a>.
See also the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a>.
</ul>
<h3 id="msg_VariableTunnelBuildReply">VariableTunnelBuildReply</h3>
@ -1014,7 +1014,7 @@ Same format as VariableTunnelBuild message, with Build Response Records.
<li>
This message was introduced in router version 0.7.12, and may not be sent to tunnel participants earlier than that version.
<li>
See also the <a href="tunnel-alt-creation.html">tunnel creation specification</a>.
See also the <a href="{{ site_url('docs/spec/tunnel-creation') }}">tunnel creation specification</a>.
</ul>

8
i2p2www/pages/site/docs/spec/plugin.html
View File

@ -277,7 +277,7 @@ But that's ok. Then you can start and stop i2ptunnel and jetty together.
So don't count on the router to automatically merge this with some existing eepsite. It probably won't happen.
Start a new I2PTunnel and Jetty from clients.config.
The best examples of this are the zzzot and pebble plugins,
available at <a href="http://stats.i2p/i2p/plugins/">zzz's plugins page</a>.
available at <a href="http://{{ i2pconv('stats.i2p') }}/i2p/plugins/">zzz's plugins page</a>.
<p>
How to get path substitution into jetty.xml?
See zzzot and pebble plugins for examples.
@ -301,7 +301,7 @@ whether or not they were previously started.
Shell script and external program notes
</h3>
<p>
To run shell scripts or other external programs, see <a href="http://zzz.i2p/topics/141">zzz.i2p</a>
To run shell scripts or other external programs, see <a href="http://{{ i2pconv('zzz.i2p') }}/topics/141">{{ i2pconv('zzz.i2p') }}</a>
<p>
To work on both Windows and Linux, write a small Java class that checks the OS type, then
runs ShellCommand on either the .bat or a .sh file you provide.
@ -346,7 +346,7 @@ could ask.
There is no reliable way to find the i2p install or config or plugin directory without using the
context API in i2p.jar.
<li>
See <a href="http://zzz.i2p/topics/16">Howto</a> for info on generating signing keys and generating/verifying keys and sud files
See <a href="http://{{ i2pconv('zzz.i2p') }}/topics/16">Howto</a> for info on generating signing keys and generating/verifying keys and sud files
<li>
All config files must be UTF-8.
<li>
@ -407,7 +407,7 @@ the entire JVM.
However, as of 0.7.13-3, this was fixed using class loaders, and now, as originally intended,
the specified classpath in clients.config is only for the particular thread.
See the section on JVM crashes below, and
<a href="http://zzz.i2p/topics/633">this thread on zzz.i2p</a> for background.
<a href="http://{{ i2pconv('zzz.i2p') }}/topics/633">this thread on zzz.i2p</a> for background.
Therefore, specify the full required classpath for each client.

20
i2p2www/pages/site/docs/spec/ssu.html
View File

@ -121,15 +121,15 @@ fragmentation to external adversaries.
<p>
DSA signatures in the SessionCreated and SessionConfirmed messages are generated using
the
<a href="common_structures_spec.html#type_SigningPublicKey">signing public key</a>
<a href="{{ site_url('docs/spec/common-structures') }}#type_SigningPublicKey">signing public key</a>
from the
<a href="common_structures_spec.html#struct_RouterIdentity">router identity</a>
<a href="{{ site_url('docs/spec/common-structures') }}#struct_RouterIdentity">router identity</a>
which is distributed out-of-band by publishing in the network database, and the associated
<a href="common_structures_spec.html#type_SigningPrivateKey">signing private key</a>.
<a href="{{ site_url('docs/spec/common-structures') }}#type_SigningPrivateKey">signing private key</a>.
</p><p>
Both introduction keys and session keys are 32 bytes,
and are defined by the
<a href="common_structures_spec.html#type_SessionKey">Common structures specification</a>.
<a href="{{ site_url('docs/spec/common-structures') }}#type_SessionKey">Common structures specification</a>.
The key used for the MAC and encryption is specified for each message below.
</p>
<p>Introduction keys are delivered through an external channel
@ -145,7 +145,7 @@ IPv6 addressing is not currently supported within I2P.
All IP addresses are currently 4 bytes.
<h3 id="time">Timestamps</h3>
While most of I2P uses 8-byte <a href="common_structures_spec.html#type_Date">Date</a> timestamps with
While most of I2P uses 8-byte <a href="{{ site_url('docs/spec/common-structures') }}#type_Date">Date</a> timestamps with
millisecond resolution, SSU uses a 4-byte timestamp with one-second resolution.
@ -238,7 +238,7 @@ This is the response to a Session Request.
<li>4 byte relay (introduction) tag which Alice can publish (else 0x00000000)</li>
<li>4 byte timestamp (seconds from the epoch) for use in the DSA
signature</li>
<li>40 byte <a href="common_structures_spec.html#type_Signature">DSA signature</a> of the critical exchanged data
<li>40 byte <a href="{{ site_url('docs/spec/common-structures') }}#type_Signature">DSA signature</a> of the critical exchanged data
(X + Y + Alice's IP + Alice's port + Bob's IP + Bob's port + Alice's
new relay tag + Bob's signed on time), encrypted with another
layer of encryption using the negotiated sessionKey. The IV
@ -326,7 +326,7 @@ bits 7-4: current identity fragment # 0-14
bits 3-0: total identity fragments (F) 1-15</pre></li>
<li>2 byte size of the current identity fragment</li>
<li>that many byte fragment of Alice's
<a href="common_structures_spec#struct_RouterIdentity">Router Identity</a>
<a href="{{ site_url('docs/spec/common-structures') }}#struct_RouterIdentity">Router Identity</a>
</li>
<li>After the last identity fragment only:
<ul><li>4 byte signed-on time
@ -334,7 +334,7 @@ bits 3-0: total identity fragments (F) 1-15</pre></li>
<li>N bytes padding, currently uninterpreted
<li>After the last identity fragment only:
<ul><li>The last 40
bytes contain the <a href="common_structures_spec.html#type_Signature">DSA signature</a> of the critical exchanged
bytes contain the <a href="{{ site_url('docs/spec/common-structures') }}#type_Signature">DSA signature</a> of the critical exchanged
data (X + Y + Alice's IP + Alice's port + Bob's IP + Bob's port
+ Alice's new relay key + Alice's signed on time)</li>
</li></ul>
@ -392,7 +392,7 @@ Typical size including header, in current implementation: 480 bytes
<ul><li>
In the current implementation, the maximum fragment size is 512 bytes.
</li><li>
The typical <a href="common_structures_spec.html#struct_RouterIdentity">Router Identity</a>
The typical <a href="{{ site_url('docs/spec/common-structures') }}#struct_RouterIdentity">Router Identity</a>
is 387 bytes, so no fragmentation is usually necessary.
</li><li>
There is no mechanism for requesting or redelivering missing fragments.
@ -735,7 +735,7 @@ the message ID must be an actual random number.
<h3 id="peerTest">PeerTest (type 7)</h3>
<p>
See <a href="{{ site_url('docs/transport/ssu') }}#peerTesting">the UDP overview page</a> for details.
See <a href="{{ site_url('docs/transport/ssu') }}#peerTesting">the SSU overview page</a> for details.
</p>
<table border="1">

34
i2p2www/pages/site/docs/spec/tunnel-creation.html
View File

@ -11,7 +11,7 @@ This page documents the current tunnel build implementation.
<p>
This document specifies the details of the encrypted tunnel build messages
used to create tunnels using a "non-interactive telescoping" method.
See <a href="tunnel-alt.html">the tunnel build document</a>
See <a href="{{ site_url('docs/tunnels/implementation') }}">the tunnel build document</a>
for an overview of the process, including peer selection and ordering methods.
<p>The tunnel creation is accomplished by a single message passed along
@ -19,11 +19,11 @@ the path of peers in the tunnel, rewritten in place, and transmitted
back to the tunnel creator. This single tunnel message is made up
of a variable number of records (up to 8) - one for each potential peer in
the tunnel. Individual records are asymmetrically
<a href="how_cryptography.html#elgamal">(ElGamal)</a>
<a href="{{ site_url('docs/how/cryptography') }}#elgamal">(ElGamal)</a>
encrypted to be
read only by a specific peer along the path, while an additional
symmetric layer of encryption
<a href="how_cryptography.html#AES">(AES)</a>
<a href="{{ site_url('docs/how/cryptography') }}#AES">(AES)</a>
is added at each hop so as to expose
the asymmetrically encrypted record only at the appropriate time.</p>
@ -32,10 +32,10 @@ Not all records must contain valid data.
The build message for a 3-hop tunnel, for example, may contain more records
to hide the actual length of the tunnel from the participants.
There are two build message types. The original
<a href="i2np_spec.html#msg_TunnelBuild">Tunnel Build Message</a> (TBM)
<a href="{{ site_url('docs/spec/i2np') }}#msg_TunnelBuild">Tunnel Build Message</a> (TBM)
contains 8 records, which is more than enough for any practical tunnel length.
The recently-implemented
<a href="i2np_spec.html#msg_VariableTunnelBuild">Variable Tunnel Build Message</a> (VTBM)
<a href="{{ site_url('docs/spec/i2np') }}#msg_VariableTunnelBuild">Variable Tunnel Build Message</a> (VTBM)
contains 1 to 8 records. The originator may trade off the size of the message
with the desired amount of tunnel length obfuscation.
<p>
@ -51,7 +51,7 @@ The reply message must be the same type and length as the build message.
<h3 id="tunnelCreate.requestRecord">Request Record Specification</h3>
Also specified in the
<a href="i2np_spec.html#struct_BuildRequestRecord">I2NP Specification</a>
<a href="{{ site_url('docs/spec/i2np') }}#struct_BuildRequestRecord">I2NP Specification</a>
<p>Cleartext of the record, visible only to the hop being asked:</p><pre>
bytes 0-3: tunnel ID to receive messages as
@ -97,14 +97,14 @@ The layer and reply key pairs are generated.
<h4 id="encryption">Request Record Encryption</h4>
<p>That cleartext record is <a href="how_cryptography.html#elgamal">ElGamal 2048 encrypted</a> with the hop's
<p>That cleartext record is <a href="{{ site_url('docs/how/cryptography') }}#elgamal">ElGamal 2048 encrypted</a> with the hop's
public encryption key and formatted into a 528 byte record:</p><pre>
bytes 0-15: First 16 bytes of the SHA-256 of the current hop's router identity
bytes 16-527: ElGamal-2048 encrypted request record</pre>
In the 512-byte encrypted record,
the ElGamal data contains bytes 1-256 and 258-513 of the
<a href="how_cryptography.html#elgamal">514-byte ElGamal encrypted block</a>.
<a href="{{ site_url('docs/how/cryptography') }}#elgamal">514-byte ElGamal encrypted block</a>.
The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed.
<p>Since the cleartext uses the full field, there is no need for
@ -129,7 +129,7 @@ are dropped.</p>
<p>After deciding whether they will agree to participate in the tunnel
or not, they replace the record that had contained the request with
an encrypted reply block. All other records are <a href="how_cryptography.html#AES">AES-256
an encrypted reply block. All other records are <a href="{{ site_url('docs/how/cryptography') }}#AES">AES-256
encrypted</a> with the included reply key and IV. Each is
encrypted separately, rather than chained across records.</p>
@ -172,17 +172,17 @@ The padding is placed before the status byte:
</p><pre>
AES-256-CBC(SHA-256(padding+status) + padding + status, key, IV)</pre>
This is also described in the
<a href="i2np_spec.html#msg_TunnelBuildReply">I2NP spec</a>.
<a href="{{ site_url('docs/spec/i2np') }}#msg_TunnelBuildReply">I2NP spec</a>.
<h3 id="tunnelCreate.requestPreparation">Tunnel Build Message Preparation</h3>
<p>When building a new Tunnel Build Messaage, all of the Build Request Records must first be
built and asymmetrically encrypted using
<a href="how_cryptography.html#elgamal">ElGamal</a>.
<a href="{{ site_url('docs/how/cryptography') }}#elgamal">ElGamal</a>.
Each record is then
premptively decrypted with the reply keys and IVs of the hops earlier in the
path, using
<a href="how_cryptography.html#AES">AES</a>.
<a href="{{ site_url('docs/how/cryptography') }}#AES">AES</a>.
That decryption should be run in reverse order so that the
asymmetrically encrypted data will show up in the clear at the
right hop after their predecessor encrypts it.</p>
@ -211,14 +211,14 @@ encrypting a reply in place of the record and encrypting all of the
other records, but since there is no 'next hop' to forward the
TunnelBuildMessage on to, it instead places the encrypted reply
records into a
<a href="i2np_spec.html#msg_TunnelBuildReply">TunnelBuildReplyMessage</a>
<a href="{{ site_url('docs/spec/i2np') }}#msg_TunnelBuildReply">TunnelBuildReplyMessage</a>
or
<a href="i2np_spec.html#msg_VariableTunnelBuildReply">VariableTunnelBuildReplyMessage</a>
<a href="{{ site_url('docs/spec/i2np') }}#msg_VariableTunnelBuildReply">VariableTunnelBuildReplyMessage</a>
(the type of message and number of records must match that of the request)
and delivers it to the
reply tunnel specified within the request record. That reply tunnel
forwards the Tunnel Build Reply Message back to the tunnel creator,
<a href="tunnel-alt.html#tunnel.operation">just as for any other message</a>.
<a href="{{ site_url('docs/tunnels/implementation') }}#tunnel.operation">just as for any other message</a>.
The tunnel creator then
processes it, as described below.</p>
@ -290,10 +290,10 @@ inject a random delay before forwarding on the request?</li>
<h2 id="ref">References</h2>
<ul>
<li>
<a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">Predecessor
<a href="http://forensics.umass.edu/pubs/wright-tissec.pdf">Predecessor
attack</a>
<li>
<a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">2008
<a href="http://forensics.umass.edu/pubs/wright.tissec.2008.pdf">2008
update</a>
<li>
<a href="http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf">Hashing it out in Public</a>

8
i2p2www/pages/site/docs/spec/tunnel-message.html
View File

@ -6,9 +6,9 @@
<h1>Tunnel Message Specification</h1>
This document specifies the format of tunnel messages.
For general information about tunnels see
<a href="tunnel-alt.html">the tunnel documentation</a>.
<a href="{{ site_url('docs/tunnels/implementation') }}">the tunnel documentation</a>.
<h2>Message preprocessing</h3>
<h2>Message preprocessing</h2>
A <i>tunnel gateway</i> is the entrance, or first hop, of a tunnel.
@ -16,7 +16,7 @@ For an outbound tunnel, the gateway is the creator of the tunnel.
For an inbound tunnel, the gateway is at the opposite end from the creator of the tunnel.
<p>
A gateway <i>preprocesses</i> <a href="i2np.html">I2NP messages</a>
A gateway <i>preprocesses</i> <a href="{{ site_url('docs/protocol/i2np') }}">I2NP messages</a>
by fragmenting and combining them into tunnel messages.
<p>
@ -28,7 +28,7 @@ observing message size.
<p>
After the tunnel messages are created, they are encrypted as described in
<a href="tunnel-alt.html">the tunnel documentation</a>.
<a href="{{ site_url('docs/tunnels/implementation') }}">the tunnel documentation</a>.
<h2 id="msg_Data">Tunnel Message (Encrypted)</h2>
These are the contents of a tunnel data message after encryption.