I2P Address: [http://git.idk.i2p]

Skip to content
Snippets Groups Projects
Commit 9567477f authored by zzz's avatar zzz
Browse files

SAM: Updates for v3.1 (ticket #1318) 

I2CP: Fix SigType names
parent 785dfcde
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
i2p2www/pages/site/docs/api/sam.html
+ 21
− 3
View file @ 9567477f
{% extends "global/layout.html" %}
{% block title %}SAM V1 Specification{% endblock %}
{% block lastupdated %}August 2010{% endblock %}
{% block accuratefor %}0.8{% endblock %}
{% block lastupdated %}June 2014{% endblock %}
{% block accuratefor %}0.9.14{% endblock %}
{% block content %}
<p>Specified below is version 1 of a simple client protocol for interacting with
I2P.
......@@ -11,6 +11,17 @@ Newer alternatives:
<a href="{{ site_url('docs/api/bob') }}">BOB</a>.
</p>
<h3>I2P 0.9.14 Changes</h3>
<p>
The reported version remains "1.0".
<ul>
<li>DEST GENERATE now supports a SIGNATURE_TYPE parameter.
<li>The MIN parameter in HELLO VERSION is now optional.
<li>The MIN and MAX parameters in HELLO VERSION now support single-digit versions such as "3".
</ul>
</p>
<h2>Version 1 Protocol</h2>
<pre>
----------------------------------------------------------------------
Simple Anonymous Messaging (SAM version 1.0) Specification
......@@ -51,7 +62,9 @@ and
HELLO REPLY RESULT=$result VERSION=1.0
The current version for both must be "1.0".
As of I2P 0.9.14, the MIN parameter is optional.
The MAX parameter must be provided and be greater than or equal to "1" and
less than "2" to use version 1.
The RESULT value may be one of:
......@@ -311,6 +324,11 @@ which is answered by
PUB=$pubkey
PRIV=$privkey
As of I2P 0.9.14, an optional parameter SIGNATURE_TYPE is supported.
The SIGNATURE_TYPE value may be any name (e.g. ECDSA_SHA256_P256, case insensitive) or number (e.g. 1)
that is supported by <a href="{{ site_url('docs/spec/common_structures') }}#type_Certificate">Key Certificates</a>.
The default is DSA_SHA1.
----------------------------------------------------------------------
RESULT values
----------------------------------------------------------------------
......
i2p2www/pages/site/docs/api/samv2.html
+ 24
− 6
View file @ 9567477f
{% extends "global/layout.html" %}
{% block title %}SAM V2 Specification{% endblock %}
{% block lastupdated %}August 2010{% endblock %}
{% block accuratefor %}0.8{% endblock %}
{% block lastupdated %}June 2014{% endblock %}
{% block accuratefor %}0.9.14{% endblock %}
{% block content %}
<p>Specified below is a simple client protocol for interacting with I2P.
</p>
......@@ -14,8 +14,9 @@ Alternatives:
<a href="{{ site_url('docs/api/bob') }}">BOB</a>.
</p>
<p />
<b>Version 2 Changes</b>
<h2>Version 2 Changes</h2>
<p>
SAM V2 was introduced in I2P release 0.6.1.31.
Compared to version 1, SAM v2 provides a way to manage several sockets
on the same I2P destination <i>in parallel</i>, i.e. the client does not
have to wait for data being successfully sent on one socket before sending
......@@ -23,7 +24,18 @@ data on another socket. All data transits through the same
client&lt;--&gt;SAM socket.
For multiple sockets, see <a href="{{ site_url('docs/api/samv3') }}">SAM V3</a>.
</p>
<h3>I2P 0.9.14 Changes</h3>
<p>
The reported version remains "2.0".
<ul>
<li>DEST GENERATE now supports a SIGNATURE_TYPE parameter.
<li>The MIN parameter in HELLO VERSION is now optional.
<li>The MIN and MAX parameters in HELLO VERSION now support single-digit versions such as "3".
</ul>
</p>
<h2>Version 2 Protocol</h2>
<pre>
----------------------------------------------------------------------
Simple Anonymous Messaging (SAM version 2.0) Specification
......@@ -64,8 +76,9 @@ and
*** HELLO REPLY RESULT=$result VERSION=2.0
*** In order to force protocol version 2.0, the values of $min and $max
*** must be "2.0".
As of I2P 0.9.14, the MIN parameter is optional.
The MAX parameter must be provided and be greater than or equal to "2" and
less than "3" to use version 2.
The RESULT value may be one of:
......@@ -378,6 +391,11 @@ which is answered by
PUB=$pubkey
PRIV=$privkey
As of I2P 0.9.14, an optional parameter SIGNATURE_TYPE is supported.
The SIGNATURE_TYPE value may be any name (e.g. ECDSA_SHA256_P256, case insensitive) or number (e.g. 1)
that is supported by <a href="{{ site_url('docs/spec/common_structures') }}#type_Certificate">Key Certificates</a>.
The default is DSA_SHA1.
----------------------------------------------------------------------
RESULT values
----------------------------------------------------------------------
......
i2p2www/pages/site/docs/api/samv3.html
+ 35
− 12
View file @ 9567477f
{% extends "global/layout.html" %}
{% block title %}SAM V3{% endblock %}
{% block lastupdated %}August 2010{% endblock %}
{% block accuratefor %}0.8{% endblock %}
{% block lastupdated %}June 2014{% endblock %}
{% block accuratefor %}0.9.14{% endblock %}
{% block content %}
<p>Specified below is a simple client protocol for interacting with I2P.
</p>
......@@ -13,8 +13,10 @@ Alternatives:
<a href="{{ site_url('docs/api/bob') }}">BOB</a>.
</p>
<p />
<b>Version 3 Changes</b>
<h2>Version 3 Changes</h2>
<h3>Version 3.0 Changes</h3>
<p>
Version 3.0 was introduced in I2P release 0.7.3.
SAM v2 provided a way to manage several sockets
on the same I2P destination <i>in parallel</i>, i.e. the client does not
have to wait for data being successfully sent on one socket before sending
......@@ -27,14 +29,24 @@ This is similar to <a href="{{ site_url('docs/api/bob') }}">BOB</a>.
<br />
SAM v3 also offers a UDP port for sending datagrams through I2P, and
can forward back I2P datagrams to the client's datagram server.
<p />
</p>
<b>Version 3 Language Libraries</b>
<h3>Version 3.1 Changes</h3>
<p>
Version 3.1 was introduced in I2P release 0.9.14.
<ul>
<li>DEST GENERATE and SESSION CREATE now support a SIGNATURE_TYPE parameter.
<li>The MIN and MAX parameters in HELLO VERSION are now optional.
<li>The MIN and MAX parameters in HELLO VERSION now support single-digit versions such as "3".
</ul>
</p>
<h2>Version 3 Language Libraries</h2>
<ul>
<li>Go - <a href="https://bitbucket.org/kallevedin/sam3">sam3</a></li>
</ul>
<b>Version 3 Protocol</b>
<h2>Version 3 Protocol</h2>
<pre>
----------------------------------------------------------------------
Simple Anonymous Messaging (SAM version 3.0) Specification
......@@ -82,10 +94,11 @@ a HELLO and the bridge sending a HELLO REPLY:
and
&lt;- HELLO REPLY RESULT=OK VERSION=3.0
&lt;- HELLO REPLY RESULT=OK VERSION=3.1
*** In order to force protocol version 3.0, the values of $min and $max
*** must be "3.0".
As of version 3.1 (I2P 0.9.14), the MIN and MAX parameters are optional.
SAM will always return the highest version possible given the
MIN and MAX constraints, or 3.1 if no constraints are given.
If the SAM bridge cannot find a suitable version, it replies with :
......@@ -122,8 +135,13 @@ received through other forms are answered with an error message) :
DESTINATION specifies what destination should be used for
sending and receiving messages/streams. It is the base 64 encoding of
the concatenation of the destination, private key, and signing private key.
If the destination is specified as TRANSIENT,
the SAM bridge creates a new destination.
If the destination is specified as TRANSIENT, the SAM bridge creates a new destination.
As of version 3.1 (I2P 0.9.14), if the destination is TRANSIENT, an optional parameter
SIGNATURE_TYPE is supported. The SIGNATURE_TYPE value may be any name
(e.g. ECDSA_SHA256_P256, case insensitive) or number (e.g. 1)
supported by <a href="{{ site_url('docs/spec/common_structures') }}#type_Certificate">Key Certificates</a>.
The default is DSA_SHA1.
{$nickname} is the choice of the client. No whitespace is allowed.
......@@ -468,6 +486,11 @@ which is answered by
PUB=$pubkey
PRIV=$privkey
As of I2P 0.9.14, an optional parameter SIGNATURE_TYPE is supported.
The SIGNATURE_TYPE value may be any name (e.g. ECDSA_SHA256_P256, case insensitive) or number (e.g. 1)
that is supported by <a href="{{ site_url('docs/spec/common_structures') }}#type_Certificate">Key Certificates</a>.
The default is DSA_SHA1.
----------------------------------------------------------------------
RESULT values
----------------------------------------------------------------------
......
i2p2www/pages/site/docs/spec/common-structures.html
+ 40
− 40
View file @ 9567477f
......@@ -133,7 +133,7 @@ This structure is used for verifying signatures.
Key type and length are inferred from context or are specified in the Key Certificate of a Destination.
{% endtrans %}
{% trans -%}
The default type is DSA-160.
The default type is DSA_SHA1.
{% endtrans %}
{% trans -%}
As of release 0.9.12, other types may be supported, depending on context.
......@@ -141,13 +141,13 @@ As of release 0.9.12, other types may be supported, depending on context.
<table border=1>
<tr><th>{% trans %}Type{% endtrans %}</th><th>{% trans %}Length (bytes){% endtrans %}</th></tr>
<tr><td>DSA-160</td><td align="center">128</td></tr>
<tr><td>ECDSA-SHA256-P256</td><td align="center">64</td></tr>
<tr><td>ECDSA-SHA384-P384</td><td align="center">96</td></tr>
<tr><td>ECDSA-SHA512-P521</td><td align="center">132</td></tr>
<tr><td>RSA-SHA256-2048</td><td align="center">256</td></tr>
<tr><td>RSA-SHA384-3072</td><td align="center">384</td></tr>
<tr><td>RSA-SHA512-4096</td><td align="center">512</td></tr>
<tr><td>DSA_SHA1</td><td align="center">128</td></tr>
<tr><td>ECDSA_SHA256_P256</td><td align="center">64</td></tr>
<tr><td>ECDSA_SHA384_P384</td><td align="center">96</td></tr>
<tr><td>ECDSA_SHA512_P521</td><td align="center">132</td></tr>
<tr><td>RSA_SHA256_2048</td><td align="center">256</td></tr>
<tr><td>RSA_SHA384_3072</td><td align="center">384</td></tr>
<tr><td>RSA_SHA512_4096</td><td align="center">512</td></tr>
</table>
<h4><a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/SigningPublicKey.html">Javadoc</a></h4>
......@@ -162,7 +162,7 @@ This structure is used for creating signatures.
Key type and length are specified when created.
{% endtrans %}
{% trans -%}
The default type is DSA-160.
The default type is DSA_SHA1.
{% endtrans %}
{% trans -%}
As of release 0.9.12, other types may be supported, depending on context.
......@@ -170,13 +170,13 @@ As of release 0.9.12, other types may be supported, depending on context.
<table border=1>
<tr><th>{% trans %}Type{% endtrans %}</th><th>{% trans %}Length (bytes){% endtrans %}</th></tr>
<tr><td>DSA-160</td><td align="center">20</td></tr>
<tr><td>ECDSA-SHA256-P256</td><td align="center">32</td></tr>
<tr><td>ECDSA-SHA384-P384</td><td align="center">48</td></tr>
<tr><td>ECDSA-SHA512-P521</td><td align="center">66</td></tr>
<tr><td>RSA-SHA256-2048</td><td align="center">512</td></tr>
<tr><td>RSA-SHA384-3072</td><td align="center">768</td></tr>
<tr><td>RSA-SHA512-4096</td><td align="center">1024</td></tr>
<tr><td>DSA_SHA1</td><td align="center">20</td></tr>
<tr><td>ECDSA_SHA256_P256</td><td align="center">32</td></tr>
<tr><td>ECDSA_SHA384_P384</td><td align="center">48</td></tr>
<tr><td>ECDSA_SHA512_P521</td><td align="center">66</td></tr>
<tr><td>RSA_SHA256_2048</td><td align="center">512</td></tr>
<tr><td>RSA_SHA384_3072</td><td align="center">768</td></tr>
<tr><td>RSA_SHA512_4096</td><td align="center">1024</td></tr>
</table>
<h4><a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/SigningPrivateKey.html">Javadoc</a></h4>
......@@ -191,7 +191,7 @@ This structure represents the signature of some data.
Signature type and length are inferred from the type of key used.
{% endtrans %}
{% trans -%}
The default type is DSA-160.
The default type is DSA_SHA1.
{% endtrans %}
{% trans -%}
As of release 0.9.12, other types may be supported, depending on context.
......@@ -199,13 +199,13 @@ As of release 0.9.12, other types may be supported, depending on context.
<table border=1>
<tr><th>{% trans %}Type{% endtrans %}</th><th>{% trans %}Length (bytes){% endtrans %}</th></tr>
<tr><td>DSA-160</td><td align="center">40</td></tr>
<tr><td>ECDSA-SHA256-P256</td><td align="center">64</td></tr>
<tr><td>ECDSA-SHA384-P384</td><td align="center">96</td></tr>
<tr><td>ECDSA-SHA512-P521</td><td align="center">132</td></tr>
<tr><td>RSA-SHA256-2048</td><td align="center">256</td></tr>
<tr><td>RSA-SHA384-3072</td><td align="center">384</td></tr>
<tr><td>RSA-SHA512-4096</td><td align="center">512</td></tr>
<tr><td>DSA_SHA1</td><td align="center">40</td></tr>
<tr><td>ECDSA_SHA256_P256</td><td align="center">64</td></tr>
<tr><td>ECDSA_SHA384_P384</td><td align="center">96</td></tr>
<tr><td>ECDSA_SHA512_P521</td><td align="center">132</td></tr>
<tr><td>RSA_SHA256_2048</td><td align="center">256</td></tr>
<tr><td>RSA_SHA384_3072</td><td align="center">384</td></tr>
<tr><td>RSA_SHA512_4096</td><td align="center">512</td></tr>
</table>
<h4><a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/Signature.html">Javadoc</a></h4>
......@@ -325,7 +325,7 @@ however non-NULL certs are not widely used, and any checking is left to the appl
<p>
Key certificates are preliminary, and are scheduled to be introduced in release 0.9.12.
Prior to that release, all PublicKeys were 256-byte ElGamal keys, and
all SigningPublicKeys were 128-byte DSA-160 keys.
all SigningPublicKeys were 128-byte DSA-SHA1 keys.
A key certificate provides a mechanism to indicate the type of the PublicKey and SigningPublicKey
in the Destination or RouterIdentity, and to package any key data in excess of the
standard lengths.
......@@ -352,13 +352,13 @@ The key certificate payload contains:
The defined Signing Key types are:
</p><table border=1>
<tr><th>Type</th><th>Type Code</th><th>Total Public Key Length</th></tr>
<tr><td>DSA-160</td><td align="center">0</td><td align="center">128</td></tr>
<tr><td>ECDSA-SHA256-P256</td><td align="center">1</td><td align="center">64</td></tr>
<tr><td>ECDSA-SHA384-P384</td><td align="center">2</td><td align="center">96</td></tr>
<tr><td>ECDSA-SHA512-P521</td><td align="center">3</td><td align="center">132</td></tr>
<tr><td>RSA-SHA256-2048</td><td align="center">4</td><td align="center">256</td></tr>
<tr><td>RSA-SHA384-3072</td><td align="center">5</td><td align="center">384</td></tr>
<tr><td>RSA-SHA512-4096</td><td align="center">6</td><td align="center">512</td></tr>
<tr><td>DSA_SHA1</td><td align="center">0</td><td align="center">128</td></tr>
<tr><td>ECDSA_SHA256_P256</td><td align="center">1</td><td align="center">64</td></tr>
<tr><td>ECDSA_SHA384_P384</td><td align="center">2</td><td align="center">96</td></tr>
<tr><td>ECDSA_SHA512_P521</td><td align="center">3</td><td align="center">132</td></tr>
<tr><td>RSA_SHA256_2048</td><td align="center">4</td><td align="center">256</td></tr>
<tr><td>RSA_SHA384_3072</td><td align="center">5</td><td align="center">384</td></tr>
<tr><td>RSA_SHA512_4096</td><td align="center">6</td><td align="center">512</td></tr>
</table>
<p>
......@@ -370,7 +370,7 @@ The defined Crypto Public Key types are:
<p>
When a Key Certificate is not present, the preceeding 384 bytes in the Destination or RouterIdentity
are defined as the 256-byte ElGamal PublicKey followed by the 128-byte DSA-160 SigningPublicKey.
are defined as the 256-byte ElGamal PublicKey followed by the 128-byte DSA-SHA1 SigningPublicKey.
When a Key Certificate is present, the preceeding 384 bytes are redefined as follows:
<ul><li>
Complete or first portion of Crypto Public Key
......@@ -393,13 +393,13 @@ the boundary between the two keys is to be specified in a future revision of thi
Example layouts using an ElGamal Crypto Public Key and the Signing Public Key type indicated:
</p><table border=1>
<tr><th>Signing Key Type</th><th>Padding Length</th><th>Excess Signing Key Data in Cert</th></tr>
<tr><td>DSA-160</td><td align="center">0</td><td align="center">0</td></tr>
<tr><td>ECDSA-SHA256-P256</td><td align="center">64</td><td align="center">0</td></tr>
<tr><td>ECDSA-SHA384-P384</td><td align="center">32</td><td align="center">0</td></tr>
<tr><td>ECDSA-SHA512-P521</td><td align="center">0</td><td align="center">4</td></tr>
<tr><td>RSA-SHA256-2048</td><td align="center">0</td><td align="center">128</td></tr>
<tr><td>RSA-SHA384-3072</td><td align="center">0</td><td align="center">256</td></tr>
<tr><td>RSA-SHA512-4096</td><td align="center">0</td><td align="center">384</td></tr>
<tr><td>DSA_SHA1</td><td align="center">0</td><td align="center">0</td></tr>
<tr><td>ECDSA_SHA256_P256</td><td align="center">64</td><td align="center">0</td></tr>
<tr><td>ECDSA_SHA384_P384</td><td align="center">32</td><td align="center">0</td></tr>
<tr><td>ECDSA_SHA512_P521</td><td align="center">0</td><td align="center">4</td></tr>
<tr><td>RSA_SHA256_2048</td><td align="center">0</td><td align="center">128</td></tr>
<tr><td>RSA_SHA384_3072</td><td align="center">0</td><td align="center">256</td></tr>
<tr><td>RSA_SHA512_4096</td><td align="center">0</td><td align="center">384</td></tr>
</table>
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

Base32 Address: [http://7qeve4v2chmjdqlwpa3vl7aojf3nodbku7vepnjwrsxljzqipz6a.b32.i2p] Onion Address: [http://47ggr2fa3vnwfyhvgskzdmr3i32eijwymxohtxsls45dulmriwxszjad.onion]