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

update i2np spec a bit

Browse Source
This commit is contained in:
dev
2010-07-26 18:46:54 +00:00
parent 85b9082857
commit 10c08196ca
1 changed files with 101 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

146
www.i2p2/pages/i2np_spec.html
View File

@ -12,65 +12,89 @@ common transports supported.
<h2 id="structures">Common structures</h2>
<h3 id="struct_header">I2NP message header</h3>
<h4>Description</h4>
<p>
Common header to all I2NP messages, which contains important information like an checksum, expiration date, etc.
</p>
<h4>Contents</h4>
<p>
1 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the type of this message, followed by an 4 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the message-id. After that there is an expiration <a href="common_structures_spec#type_Date">Date</a>, followed by an 2 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the length of the message payload, followed by an <a href="common_structures_spec#type_Hash">Hash</a>, which is truncated to the first byte. After that the actual message data follows.
</p>
<pre>
{% filter escape %}
+----+----+----+----+----+
|type| msg-id |
+----+----+----+----+----+----+----+----+
|type| msg-id | expiration
| expiration |
+----+----+----+----+----+----+----+----+
date | size |chks|
+----+----+----+----+----+----+----+----+
| data .....
+----+---//
| size |chks|
+----+----+----+
{% endfilter %}
</pre>
<h4>Definition</h4>
<pre>
{% filter escape %}
type:
1 byte
identifies the message type(see table below)
type :: Integer
length -> 1 byte
msg-id:
4 bytes
uniquely identifies this message(for some time at least)
purpose -> identifies the message type(see table below)
expiration:
msg-id :: Integer
length -> 4 bytes
purpose -> uniquely identifies this message(for some time at least)
expiration :: Date
8 bytes
date this message will expire
size:
2 bytes
length of the payload
size :: Integer
length -> 2 bytes
chks:
1 byte
checksum of the payload
purpose -> length of the payload
chks :: Hash
length -> 1 byte
purpose -> checksum of the payload
SHA256 hash truncated to the first byte
data:
$size bytes
actual message contents
data :: Data
length -> $size bytes
purpose -> actual message contents
{% endfilter %}
</pre>
<h3 id="struct_BuildRequestRecord">BuildRequestRecord</h3>
<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 here.
</p>
<h4>Contents</h4>
<p>
<a href="common_structures_spec#type_TunnelId">TunnelId</a> to receive messages on, followed by the <a href="common_structures_spec#type_Hash">Hash</a> of our <a href="common_structures_spec#struct_RouterIdentity">RouterIdentity</a>. After that the <a href="common_structures_spec#type_TunnelId">TunnelId</a> and the <a href="common_structures_spec#type_Hash">Hash</a> of the next router's <a href="common_structures_spec#struct_RouterIdentity">RouterIdentity</a> follow.
</p>
<h4>Definition</h4>
<pre>
{% filter escape %}
Cleartext:
+----+----+----+----+----+----+----+----+
| receive tunnelId | local routerInfo |
+----+----+----+----+ hash +
| receive_tunnel | our_ident |
+----+----+----+----+ +
| |
+ +
| |
+ +
| |
+ +----+----+----+----+
| | send tunnelId |
| | next_tunnel |
+----+----+----+----+----+----+----+----+
| nexthop routerInfo hash |
| next_ident |
+ +
| |
+ +
@ -78,7 +102,7 @@ Cleartext:
+ +
| |
+----+----+----+----+----+----+----+----+
| AES256 tunnel layer key |
| layer_key |
+ +
| |
+ +
@ -86,7 +110,7 @@ Cleartext:
+ +
| |
+----+----+----+----+----+----+----+----+
| AES256 tunnel IV key |
| iv_key |
+ +
| |
+ +
@ -94,7 +118,7 @@ Cleartext:
+ +
| |
+----+----+----+----+----+----+----+----+
| AES256 reply key |
| reply_key |
+ +
| |
+ +
@ -102,12 +126,12 @@ Cleartext:
+ +
| |
+----+----+----+----+----+----+----+----+
| reply IV |
| reply_iv |
+ +
| |
+----+----+----+----+----+----+----+----+
|flag| request time | next msg-id
+----+----+----+----+----+----+----+----+
+----+----+----+----+----+----+----+----+----+
|flag| request_time | send_message_id |
+----+----+----+----+----+----+----+----+----+
| padding...
+----+----+----+--//
@ -127,23 +151,51 @@ encrypted:
<pre>
{% filter escape %}
unencrypted:
* bytes 0-3: tunnel ID to receive messages as
* bytes 4-35: local router identity hash
* bytes 36-39: next tunnel ID
* bytes 40-71: next router identity hash
* bytes 72-103: AES-256 tunnel layer key
* bytes 104-135: AES-256 tunnel IV key
* bytes 136-167: AES-256 reply key
* bytes 168-183: reply IV
* byte 184: flags
* bytes 185-188: request time (in hours since the epoch)
* bytes 189-192: next message ID
* bytes 193-222: uninterpreted / random padding
Taken from i2p.i2p/router/java/src/net/i2p/data/i2np/BuildRequestRecord.java
receive_tunnel :: TunnelId
length -> 4 bytes
our_ident :: Hash
length -> 32 bytes
next_tunnel :: TunnelId
length -> 4 bytes
next_ident :: Hash
length -> 32 bytes
layer_key :: SessionKey
length -> 32 bytes
iv_key :: SessionKey
length -> 32 bytes
reply_key :: SessionKey
length -> 32 bytes
reply_iv :: Integer
length -> 16 bytes
flag :: Integer
length -> 1 byte
request_time :: Integer
length -> 4 bytes
send_message_id :: Integer
length -> 4 bytes
padding :: Data
length -> 29 bytes
source -> random
encrypted:
bytes 0-15: SHA-256-128(SHA256 hash truncated to 128bit) of the current hop's identity (the toPeer parameter)
bytes 15-527: ElGamal-2048 encrypted block
toPeer :: Hash
length -> 16 bytes
encrypted_data :: ElGamal-2048 encrypted data
length -> 514
{% endfilter %}
</pre>