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

SSU: Clarify intro/session keys

Browse Source 
Links: More naming of 0x90, by request
This commit is contained in:
zzz
2014-02-16 17:59:56 +00:00
parent 3a244f5d21
commit b71c676a97
3 changed files with 70 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
i2p2www/pages/site/about/media.html
View File

@@ -168,14 +168,14 @@ Adrian Crenshaw.
<li>{% trans link1='http://invisibleip.sourceforge.net/iip/mediaDCInterview1.php',
link2='http://invisibleip.sourceforge.net/iip/mediaDCInterview2.php' -%}
0x90 Interviewed by DistributedCity
Lance James (0x90) Interviewed by DistributedCity
<a href="{{ link1 }}">Part 1</a>
<a href="{{ link2 }}">Part 2</a>
July 26, 2002.
{%- endtrans %}</li>
<li>{% trans link='http://invisibleip.sourceforge.net/iip/resources/elpais-iip.txt' -%}
0x90 Interviewed by El Pais
Lance James (0x90) Interviewed by El Pais
(original in Spanish)
<a href="{{ link }}">English translation</a>
October 31, 2002.
@@ -214,5 +214,17 @@ November 11, 2011.
February 16, 2012
{%- endtrans %}</li>
</ul>
<h2>{{ _('Other') }}</h2>
<ul>
<li>{% trans -%}
I2P mentioned in Netflix's "House of Cards" Season 2 Episode 2,
February 14, 2014
{%- endtrans %}</li>
</ul>
</div>
{% endblock %}

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

@@ -266,7 +266,7 @@ This is the first message sent to establish a session.
<li>N bytes, currently uninterpreted</li>
</ul></td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>
<td>introKey</td></tr>
<td>Bob's introKey, as retrieved from the network database</td></tr>
</table>
<p>Message format:</p>
@@ -324,7 +324,7 @@ This is the response to a Session Request.
<li>N bytes, currently uninterpreted</li>
</ul></td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>
<td>introKey, with an additional layer of encryption over the 40 byte
<td>Bob's introKey, with an additional layer of encryption over the 40 byte
signature and the following 8 bytes padding.</td></tr>
</table>
@@ -378,6 +378,9 @@ and Bob is unaware of it, the verification by Alice will fail.
See <a href="#keys">the Keys section above</a> for details on DSA signatures.
Alice already has Bob's public signing key, from the network database.
</li><li>
This is the only message that uses the sender's intro key.
All others use the receiver's intro key or the established session key.
</li><li>
Signed-on time appears to be unused or unverified in the current implementation.
</li><li>
The uninterpreted data could possibly be used in the future for challenges.
@@ -416,7 +419,7 @@ bits 3-0: total identity fragments (F) 1-15</pre></li>
</li></ul>
</ul></td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>
<td>sessionKey</td></tr>
<td>Alice/Bob sessionKey, as generated from the DH exchange</td></tr>
</table>
<p>
@@ -510,7 +513,7 @@ and is sent as of release 0.8.9.
<td>none
</td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>
<td>sessionKey or introKey</td></tr>
<td>Alice/Bob sessionKey</td></tr>
</table>
@@ -520,6 +523,12 @@ Typical size including header, in current implementation: 48 bytes
(before non-mod-16 padding)
</p>
<h4>Notes</h4>
<ul><li>
Destroy messages received with the sender's or receiver's intro key will be ignored.
</li></ul>
<h3 id="relayRequest">RelayRequest (type 3)</h3>
<p>
This is the first message sent from Alice to Bob to request an introduction to Charlie.
@@ -541,7 +550,7 @@ This is the first message sent from Alice to Bob to request an introduction to C
<li>N bytes, currently uninterpreted</li>
</ul></td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>
<td>introKey (or sessionKey, if Alice/Bob is established)</td></tr>
<td>Bob's introKey, as retrieved from the network database (or Alice/Bob sessionKey, if established)</td></tr>
</table>
<p>Message format:</p>
@@ -587,6 +596,10 @@ If Alice includes her address/port, Bob may perform additional validation before
Challenge is unimplemented, challenge size is always zero
</li><li>
There are no plans to implement relaying for IPv6.
</li><li>
Prior to release 0.9.12, Bob's intro key was always used.
As of release 0.9.12, the session key is used if there is an established session
between Alice and Bob.
</li></ul>
@@ -610,7 +623,7 @@ This is the response to a Relay Request and is sent from Bob to Alice.
<li>N bytes, currently uninterpreted</li>
</ul></td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>
<td>introKey (or sessionKey, if Alice/Bob is established)</td></tr>
<td>Alice's introKey, as received in the Relay Request (or Alice/Bob sessionKey, if established)</td></tr>
</table>
<p>Message format:</p>
@@ -644,6 +657,10 @@ Charlie's IP address must be IPv4, as that is the address that Alice will send
the SessionRequest to after the Hole Punch.
</li><li>
There are no plans to implement relaying for IPv6.
</li><li>
Prior to release 0.9.12, Alice's intro key was always used.
As of release 0.9.12, the session key is used if there is an established session
between Alice and Bob.
</li></ul>
@@ -666,7 +683,7 @@ This is the introduction for Alice, which is sent from Bob to Charlie.
<li>N bytes, currently uninterpreted</li>
</ul></td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>
<td>sessionKey</td></tr>
<td>Bob/Charlie sessionKey</td></tr>
</table>
<p>Message format:</p>
@@ -867,14 +884,37 @@ See <a href="{{ site_url('docs/transport/ssu') }}#peerTesting">the SSU overview
<tr><td align="right" valign="top"><b>Data:</b></td>
<td><ul>
<li>4 byte nonce</li>
<li>1 byte IP address size</li>
<li>that many byte representation of Alice's IP address</li>
<li>1 byte IP address size (may be zero)</li>
<li>that many byte representation of Alice's IP address, if size &gt; 0</li>
<li>2 byte Alice's port number</li>
<li>Alice's 32-byte introduction key</li>
<li>Alice's or Charlie's 32-byte introduction key</li>
<li>N bytes, currently uninterpreted</li>
</ul></td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>
<td>introKey (or sessionKey if the connection has already been established)</td></tr>
<td>
Listed in order of occurrence:
<ol><li>
When sent from Alice to Bob:
Alice/Bob sessionKey
(the protocol also permits Bob's introKey if Alice and Bob do not have an established session,
but in the current implementation Alice always selects a Bob that is established)
</li><li>
When sent from Bob to Charlie:
Bob/Charlie sessionKey
</li><li>
When sent from Charlie to Bob:
Bob/Charlie sessionKey
</li><li>
When sent from Bob to Alice:
Alice's introKey, as received in the Peer Test message from Alice
</li><li>
When sent from Charlie to Alice:
Alice's introKey, as received in the Peer Test message from Bob
</li><li>
When sent from Alice to Charlie:
Charlie's introKey, as received in the Peer Test message from Charlie
</li></ol>
</td></tr>
</table>
<p>Message format:</p>

9
i2p2www/pages/site/docs/transport/ssu.html
View File

@@ -138,13 +138,14 @@ For connections using the larger MTU, larger messages are possible.
<p>{% trans -%}
All encryption used is AES256/CBC with 32 byte keys and 16 byte IVs.
The MAC and session keys are negotiated as part of the DH exchange, used
for the HMAC and encryption, respectively. Prior to the DH exchange,
the publicly knowable introKey is used for the MAC and encryption.
When Alice originates a session with Bob,
the MAC and session keys are negotiated as part of the DH exchange, and are then used
for the HMAC and encryption, respectively. During the DH exchange,
Bob's publicly knowable introKey is used for the MAC and encryption.
{%- endtrans %}</p>
<p>{% trans -%}
When using the introKey, both the initial message and any subsequent
Both the initial message and the subsequent
reply use the introKey of the responder (Bob) - the responder does
not need to know the introKey of the requester (Alice). The DSA
signing key used by Bob should already be known to Alice when she