{% trans transports=site_url('docs/transport'), ssu=site_url('docs/transport/ssu') -%} NTCP is one of two transports currently implemented in I2P. The other is SSU. NTCP is a Java NIO-based transport introduced in I2P release 0.6.1.22. Java NIO (new I/O) does not suffer from the 1 thread per connection issues of the old TCP transport. {%- endtrans %}
{% trans -%} By default, NTCP uses the IP/Port auto-detected by SSU. When enabled on config.jsp, SSU will notify/restart NTCP when the external address changes or when the firewall status changes. Now you can enable inbound TCP without a static IP or dyndns service. {%- endtrans %}
{% trans -%} The NTCP code within I2P is relatively lightweight (1/4 the size of the SSU code) because it uses the underlying Java TCP transport for reliable delivery. {%- endtrans %}
{% trans -%} After establishment, the NTCP transport sends individual I2NP messages, with a simple checksum. The unencrypted message is encoded as follows: {%- endtrans %}
{% highlight lang='dataspec' %} +-------+-------+--//--+---//----+-------+-------+-------+-------+ | sizeof(data) | data | padding | Adler checksum of sz+data+pad | +-------+-------+--//--+---//----+-------+-------+-------+-------+ {% endhighlight %}{% trans -%} The data is then AES/256/CBC encrypted. The session key for the encryption is negotiated during establishment (using Diffie-Hellman 2048 bit). The establishment between two routers is implemented in the EstablishState class and detailed below. The IV for AES/256/CBC encryption is the last 16 bytes of the previous encrypted message. {%- endtrans %}
{% trans -%} 0-15 bytes of padding are required to bring the total message length (including the six size and checksum bytes) to a multiple of 16. The maximum message size is currently 16 KB. Therefore the maximum data size is currently 16 KB - 6, or 16378 bytes. The minimum data size is 1. {%- endtrans %}
{% trans -%} One special case is a metadata message where the sizeof(data) is 0. In that case, the unencrypted message is encoded as: {%- endtrans %}
{% highlight lang='dataspec' %} +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | timestamp in seconds | uninterpreted +-------+-------+-------+-------+-------+-------+-------+-------+ uninterpreted | Adler checksum of bytes 0-11 | +-------+-------+-------+-------+-------+-------+-------+-------+ {% endhighlight %}{% trans -%} Total length: 16 bytes. The time sync message is sent at approximately 15 minute intervals. The message is encrypted just as standard messages are. {%- endtrans %}
{% trans rfc1950='http://tools.ietf.org/html/rfc1950' -%} The standard and time sync messages use the Adler-32 checksum as defined in the ZLIB Specification. {%- endtrans %}
{% trans -%} In the establish state, there is a 4-phase message sequence to exchange DH keys and signatures. In the first two messages there is a 2048-bit Diffie Hellman exchange. Then, DSA signatures of the critical data are exchanged to confirm the connection. {%- endtrans %}
{% highlight %} Alice contacts Bob ========================================================= X+(H(X) xor Bob.identHash)-----------------------------> <----------------------------------------Y+E(H(X+Y)+tsB+padding, sk, Y[239:255]) E(sz+Alice.identity+tsA+padding+S(X+Y+Bob.identHash+tsA+tsB), sk, hX_xor_Bob.identHash[16:31])---> <----------------------E(S(X+Y+Alice.identHash+tsA+tsB)+padding, sk, prev) {% trans %}Legend:{% endtrans %} X, Y: {% trans %}256 byte DH public keys{% endtrans %} H(): 32 byte SHA256 Hash E(data, session key, IV): AES256 Encrypt S(): 40 byte DSA Signature tsA, tsB: {% trans %}timestamps (4 bytes, seconds since epoch){% endtrans %} sk: {% trans %}32 byte Session key{% endtrans %} sz: {% trans %}2 byte size of Alice identity to follow{% endtrans %} {% endhighlight %}{% trans cryptography=site_url('docs/how/cryptography') -%} The initial 2048-bit DH key exchange uses the same shared prime (p) and generator (g) as that used for I2P's ElGamal encryption. {%- endtrans %}
{% trans -%} The DH key exchange consists of a number of steps, displayed below. The mapping between these steps and the messages sent between I2P routers, is marked in bold. {%- endtrans %}
X = g^x mod p.{% endtrans %}Y = g^y mod p.{% endtrans %}sessionKey = Y^x mod p.{% endtrans %}sessionKey = X^y mod p.{% endtrans %}sessionKey = g^(x*y) mod p.{% endtrans %}{% trans -%} The sessionKey is then used to exchange identities in Message 3 and Message 4. {%- endtrans %}
{% trans commonstructures=site_url('docs/spec/common-structures'), netdb=site_url('docs/how/network-database') -%} This is the DH request. Alice already has Bob's Router Identity, IP address, and port, as contained in his Router Info, which was published to the network database. Alice sends Bob: {%- endtrans %}
{% highlight %} X+(H(X) xor Bob.identHash)-----------------------------> {% trans %}Size:{% endtrans %} 288 bytes {% endhighlight %}{% trans %}Contents:{% endtrans %}
+----+----+----+----+----+----+----+----+
| X, as calculated from DH |
+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| HXxorHI |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
X: {% trans %}256 byte X from Diffie Hellman{% endtrans %}
HXxorHI: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
SHA256 Hash(X) xored with SHA256 Hash(Bob's Router Identity)
{%- endtrans %}
(32 bytes)
{% trans %}Notes:{% endtrans %}
{% trans -%} This is the DH reply. Bob sends Alice: {%- endtrans %}
{% highlight %} <----------------------------------------Y+E(H(X+Y)+tsB+padding, sk, Y[239:255]) {% trans %}Size:{% endtrans %} 304 bytes {% endhighlight %}{% trans %}Unencrypted Contents:{% endtrans %}
{% highlight lang='dataspec' %} +----+----+----+----+----+----+----+----+ | Y as calculated from DH | + + | | ~ . . . ~ | | +----+----+----+----+----+----+----+----+ | | + + | HXY | + + | | + + | | +----+----+----+----+----+----+----+----+ | tsB | padding | +----+----+----+----+ + | | +----+----+----+----+----+----+----+----+ Y: {% trans %}256 byte Y from Diffie Hellman{% endtrans %} HXY: {% trans %}SHA256 Hash(X concatenated with Y){% endtrans %} (32 bytes) tsB: {% trans %}4 byte timestamp (seconds since the epoch){% endtrans %} padding: {% trans %}12 bytes random data{% endtrans %} {% endhighlight %}{% trans %}Encrypted Contents:{% endtrans %}
+----+----+----+----+----+----+----+----+
| Y as calculated from DH |
+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| encrypted data |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
Y: {% trans %}256 byte Y from Diffie Hellman{% endtrans %}
encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
48 bytes AES encrypted using the DH session key and
the last 16 bytes of Y as the IV{% endtrans %}
{% trans %}Notes:{% endtrans %}
{% trans -%} This contains Alice's router identity, and a DSA signature of the critical data. Alice sends Bob: {%- endtrans %}
{% highlight %} E(sz+Alice.identity+tsA+padding+S(X+Y+Bob.identHash+tsA+tsB), sk, hX_xor_Bob.identHash[16:31])---> {% trans %}Size:{% endtrans %} 448 bytes (typ. for 387 byte identity) {% endhighlight %}{% trans %}Unencrypted Contents:{% endtrans %}
+----+----+----+----+----+----+----+----+
| sz | Alice's Router Identity |
+----+----+ +
| |
~ . . . ~
| |
+ +----+----+----+
| | tsA
+----+----+----+----+----+----+----+----+
| padding |
+----+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| signature |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
sz: {% trans %}2 byte size of Alice's router identity to follow (should always be 387){% endtrans %}
ident: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
Alice's 387 byte Router Identity
{%- endtrans %}
tsA: {% trans %}4 byte timestamp (seconds since the epoch){% endtrans %}
padding: {% trans %}15 bytes random data{% endtrans %}
signature: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
the 40 byte DSA signature of the following concatenated data:
X, Y, Bob's Router Identity, tsA, tsB.
Alice signs it with the private signing key associated with the public signing key in her Router Identity
{%- endtrans %}
{% trans %}Encrypted Contents:{% endtrans %}
+----+----+----+----+----+----+----+----+
| |
+ +
| encrypted data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
448 bytes AES encrypted using the DH session key and
the last 16 bytes of HXxorHI (i.e., the last 16 bytes of message #1) as the IV
{%- endtrans %}
{% trans %}Notes:{% endtrans %}
{% trans -%} This is a DSA signature of the critical data. Bob sends Alice: {%- endtrans %}
{% highlight %} * <----------------------E(S(X+Y+Alice.identHash+tsA+tsB)+padding, sk, prev) {% trans %}Size:{% endtrans %} 48 bytes {% endhighlight %}{% trans %}Unencrypted Contents:{% endtrans %}
+----+----+----+----+----+----+----+----+
| |
+ +
| signature |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| padding |
+----+----+----+----+----+----+----+----+
signature: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
the 40 byte DSA signature of the following concatenated data:
X, Y, Alice's Router Identity, tsA, tsB.
Bob signs it with the private signing key associated with the public signing key in his Router Identity
{%- endtrans %}
padding: {% trans %}8 bytes random data{% endtrans %}
{% trans %}Encrypted Contents:{% endtrans %}
+----+----+----+----+----+----+----+----+
| |
+ +
| encrypted data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
48 bytes AES encrypted using the DH session key and
the last 16 bytes of the encrypted contents of message #2 as the IV
{%- endtrans %}
Notes:
{% trans -%} The connection is established, and standard or time sync messages may be exchanged. All subsequent messages are AES encrypted using the negotiated DH session key. Alice will use the last 16 bytes of the encrypted contents of message #3 as the next IV. Bob will use the last 16 bytes of the encrypted contents of message #4 as the next IV. {%- endtrans %}
{% trans -%} Alternately, when Bob receives a connection, it could be a check connection (perhaps prompted by Bob asking for someone to verify his listener). Check Connection is not currently used. However, for the record, check connections are formatted as follows. A check info connection will receive 256 bytes containing: {%- endtrans %}
{% trans ntcpdisc=site_url('docs/discussions/ntcp') -%} Now on the NTCP Discussion Page. {%- endtrans %}