Streaming changes for proposal 123

Streaming versions chart
I2CP fixes for CreateLeaseSet2 Message
Start of blinding changes in proposal 123

i2p2www/pages/site/docs/protocol/i2cp.html

@@ -181,10 +181,10 @@ of sending a MessageStatus and awaiting a ReceiveMessageBegin.
 <td>0-65535,...
 <td>0
 <td>
-The encryption type to be used.
+The encryption type to be used, as of 0.9.38.
 Interpreted client-side, but also passed to the router in the
 SessionConfig, to declare intent and check support.
-May be comma-separated values for multiple types.
+As of 0.9.39, may be comma-separated values for multiple types.
 See PublicKey in common strutures spec for values.
 See proposals 123, 144, and 145.
 </td>
@@ -613,10 +613,10 @@ of sending a MessageStatus and awaiting a ReceiveMessageBegin.
 <td>0-65535,...
 <td>0
 <td>
-The encryption type to be used.
+The encryption type to be used, as of 0.9.38.
 Interpreted client-side, but also passed to the router in the
 SessionConfig, to declare intent and check support.
-May be comma-separated values for multiple types.
+As of 0.9.39, may be comma-separated values for multiple types.
 See PublicKey in common strutures spec for values.
 See proposals 123, 144, and 145.
 </td>

i2p2www/spec/i2cp.rst

@@ -3,7 +3,7 @@ I2CP Specification
 ==================
 .. meta::
     :category: Protocols
-    :lastupdated: January 2019
+    :lastupdated: February 2019
     :accuratefor: 0.9.38
 
 .. contents::
@@ -420,7 +420,7 @@ Message Types
 ===============================  =========  ====  =====
 BandwidthLimitsMessage_           R -> C     23   0.7.2
 CreateLeaseSetMessage_            C -> R      4
-CreateLeaseSet2Message_           C -> R     40   0.9.38
+CreateLeaseSet2Message_           C -> R     40   0.9.39
 CreateSessionMessage_             C -> R      1
 DestLookupMessage_                C -> R     34   0.7
 DestReplyMessage_                 R -> C     35   0.7
@@ -532,22 +532,13 @@ Contents
    Type 5 is a [EncryptedLeaseSet]_
    Type 7 is a [MetaLeaseSet]_
 3. [LeaseSet]_ or [LeaseSet2]_ or [EncryptedLeaseSet]_ or [MetaLeaseSet]_
-4. [SigningPrivateKey]_ type and length as inferred from the lease set signature
+4. [PrivateKey]_ list.
-   (by Destination or transient signing key).
-   Not present for MetaLeaseSet.
-5. [PrivateKey]_ list.
    One for each public key in the lease set, in the same order.
    Types and lengths as inferred from the public keys in the lease set.
    Not present for MetaLeaseSet.
 
 Notes
 `````
-The SigningPrivateKey matches the [SigningPublicKey]_ from within the LeaseSet.
-This is for LeaseSet revocation,
-which is unimplemented and is unlikely to ever be implemented.
-It may be acceptable to put random data or zeros here, but the length must be correct.
-This field may be repurposed for EncryptedLeaseSet.
-
 The PrivateKeys match each of the [PublicKey]_ from the LeaseSet.
 The PrivateKeys are necessary for decrypting garlic routed messages.
 
@@ -558,7 +549,11 @@ The contents and format for MetaLeaseSet are preliminary and subject to change.
 There is no protocol specified for administration of multiple routers.
 See proposal 123 for more information.
 
-Revocation is unimplemented.
+The signing private key, previously defined for revocation and unused,
+is not present in LS2.
+
+Preliminary implementation was in 0.9.38 but the definition above changed.
+Not valid until 0.9.39.
 
 
 .. _msg-CreateSession:

i2p2www/spec/proposals/123-new-netdb-entries.rst

@@ -5,7 +5,7 @@ New netDB Entries
     :author: zzz, str4d, orignal
     :created: 2016-01-16
     :thread: http://zzz.i2p/topics/2051
-    :lastupdated: 2019-01-27
+    :lastupdated: 2019-02-03
     :status: Open
     :supercedes: 110, 120, 121, 122
 
@@ -525,7 +525,7 @@ SIG
 
 DH
     X25519 public key agreement system. Private keys of 32 bytes, public keys of 32
-    bytes, produces outputs of 32 bytes. 32 = 32. It has the following
+    bytes, produces outputs of 32 bytes. It has the following
     functions:
 
     GENERATE_PRIVATE()
@@ -644,8 +644,7 @@ Flags
 
     Bit 0: 0 for everybody, 1 for per-client, auth section to follow
 
-    Bits 3-1: Authentication scheme, only if bit 1 is set to 1 for per-client,
+    Bits 3-1: Authentication scheme, only if bit 1 is set to 1 for per-client, otherwise 0
-              otherwise 0
               0: DH client authentication (or no per-client authentication)
               1: PSK client authentication
 
@@ -716,22 +715,19 @@ Data
 Blinding Key Derivation
 ```````````````````````
 
-We propose the following scheme for key blinding, based on Ed25519.
+We use the following scheme for key blinding, based on Ed25519
+and ZCash RedDSA [ZCASH]_.
 
-(This is an ECC group, so remember that scalar multiplication is the
+We do not use Tor's rend-spec-v3.txt appendix A.2 [TOR-REND-SPEC-V3]_,
-trapdoor function, and it's defined in terms of iterated point
+which has similar design goals, because its blinded public keys
-addition. See the Ed25519 paper [ED25519-REFS]_ for a fairly
+may be off the prime-order subgroup, with unknown security implications.
-clear writeup.)
 
-Copied from Tor rend-spec-v3.txt appendix A.2
+The RedDSA signatures are over the Ed25519 curve, using SHA-512 for the hash.
-which has similar design goals [TOR-REND-SPEC-V3]_.
-
-Changes for I2P TODO
 
 
 ::
 
-  Let B be the ed25519 basepoint as found in section 5 of [ED25519-B-REF]:
+  Let B be the ed25519 base point as in [ED25519-REFS]:
       B = (15112221349535400772501151409588531511454012693041857206046113283949847762202,
            46316835694926478169428394003475163141307993866256225615783033603165251855960)
 
@@ -1395,6 +1391,12 @@ For Service Record and Service List,
 preliminary and unscheduled.
 
 
+New Signature Type
+------------------
+
+Add RedDSA_SHA256_Ed25519 Type 11.
+
+
 
 Encryption Spec Changes Required
 ================================
@@ -1551,14 +1553,7 @@ Justification
   For for common parsing code, it's easier to know it from the message itself.
 
 - The signing private key, previously defined for revocation and unused,
-  was before the leaseset so the type and length was unknown.
+  is not present in LS2.
-  Clients always set it to the DSA length.
-  For proposal 144, the key may be required, and must match the type
-  of the destination signing key (or transient signing key if offline sigs are used).
-  For the router to know the type and length of the private key,
-  it must be after the lease set, unless the parser knows the type before hand
-  in the session config.
-  For for common parsing code, it's easier to know it from the message itself.
 
 Message Type
 ````````````
@@ -1578,9 +1573,6 @@ Format
              Type 5 is a encrypted LS2
              Type 7 is a meta LS2
   LeaseSet: type specified above
-  Signing Private Key: type as inferred from the lease set signature
-                       (by dest signing key or transient key)
-                       Not present for Meta LS2
   Encryption Private Keys: One for each public key in the lease set, in the same order
                            Types as inferred from the public keys in the lease set
                            Not present for Meta LS2
@@ -1589,8 +1581,8 @@ Format
 Notes
 `````
 
-- Minimum router version is 0.9.38.
+- Minimum router version is 0.9.39.
-
+  Preliminary implementation was in 0.9.38 but the definition above changed.
 
 
 Issues
@@ -1768,7 +1760,7 @@ Changes
   Option order: 4
   Option data:  Variable bytes
   Function:     Contains the offline signature section from LS2.
-                SIGNATURE_INCLUDED must also be set.
+                FROM_INCLUDED must also be set.
                 Expires timestamp (4 bytes, seconds since epoch, rolls over in 2106)
                 Transient sig type (2 bytes)
                 Transient signing public key (length as implied by sig type)
@@ -1908,3 +1900,6 @@ References
 
 .. [UNSCIENTIFIC-KDF-SPEEDS]
     https://www.lvh.io/posts/secure-key-derivation-performance.html
+
+.. [ZCASH]
+   https://github.com/zcash/zips/tree/master/protocol/protocol.pdf

i2p2www/spec/streaming.rst

@@ -3,8 +3,8 @@ Streaming Library Specification
 ===============================
 .. meta::
     :category: Protocols
-    :lastupdated: June 2015
+    :lastupdated: February 2019
-    :accuratefor: 0.9.20
+    :accuratefor: 0.9.39
 
 .. contents::
 
@@ -15,6 +15,44 @@ Overview
 See [STREAMING]_ for an overview of the Streaming Library.
 
 
+.. _versions:
+
+Protocol Versions
+=================
+
+The streaming protocol does not include a version field.
+The versions listed below are for Java I2P.
+Implementations and actual crypto support may vary.
+There is no way to determine if the far-end supports any particular version or feature.
+The table below is for general guidance as to the release dates for various features.
+
+The features listed below are for the protocol itself.
+Various options for configuration are documented in [STREAMING]_ along with the
+Java I2P version in which they were implemented.
+
+
+==============  ================================================================
+Router Version  Streaming Features
+==============  ================================================================
+   0.9.39       OFFLINE_SIGNATURE option
+
+   0.9.36       I2CP protocol number enforced
+
+   0.9.20       FROM_INCLUDED no longer required in RESET
+
+   0.9.18       PINGs and PONGs may include a payload
+
+   0.9.15       EdDSA Ed25519 sig type
+
+   0.9.12       ECDSA P-256, P-384, and P-521 sig types
+
+   0.9.11       Variable-length signatures
+
+   0.7.1        Protocol numbers defined in I2CP
+
+==============  ================================================================
+
+
 Protocol Specification
 ======================
 
@@ -93,6 +131,8 @@ The format of a single packet in the streaming protocol is:
   payload :: remaining packet size
 {% endhighlight %}
 
+
+
 Flags and Option Data Fields
 ----------------------------
 
@@ -116,7 +156,7 @@ Bit order: 15....0 (15 is MSB)
   2    RESET                          --             --         Abnormal close. SIGNATURE_INCLUDED must also be set. Prior to
                                                                 release 0.9.20, due to a bug, FROM_INCLUDED must also be set.
 
-  3    SIGNATURE_INCLUDED              4       variable length  Currently sent only with SYNCHRONIZE, CLOSE, and RESET, where
+  3    SIGNATURE_INCLUDED              5       variable length  Currently sent only with SYNCHRONIZE, CLOSE, and RESET, where
                                                [Signature]_     it is required, and with ECHO, where it is required for a
                                                                 ping. The signature uses the Destination's [SigningPrivateKey]_
                                                                 to sign the entire header and payload with the space in the
@@ -151,16 +191,36 @@ Bit order: 15....0 (15 is MSB)
                                                                 does not save any space, the ackThrough field is before the
                                                                 flags and is always present.
 
-11-15  unused                                                   Set to zero for compatibility with future uses.
+ 11    OFFLINE_SIGNATURE               4       variable length  Contains the offline signature section from LS2.
+                                               [OfflineSig]_    See proposal 123 and the common structures specification.
+                                                                FROM_INCLUDED must also be set.
+                                                                Contains an [OfflineSig]_:
+                                                                1) Expires timestamp (4 bytes, seconds since epoch, rolls over in 2106)
+                                                                2) Transient sig type (2 bytes)
+                                                                3) Transient [SigningPublicKey]_ (length as implied by sig type)
+                                                                4) [Signature]_ of expires timestamp, transient sig type, and public key,
+                                                                by the destination public key. Length of sig as implied by
+                                                                by the destination public key sig type.
+
+12-15  unused                                                   Set to zero for compatibility with future uses.
 =====  ========================  ============  ===============  ===============================================================
 
+
+
 Variable Length Signature Notes
 ```````````````````````````````
 Prior to release 0.9.11, the signature in the option field was always 40 bytes.
+
 As of release 0.9.11, the signature is variable length.  The Signature type and
 length are inferred from the type of key used in the FROM_INCLUDED option and
 the [Signature]_ documentation.
 
+As of release 0.9.39, the OFFLINE_SIGNATURE option is supported.
+If this option is present, the transient [SigningPublicKey]_
+is used to verify any signed packets, and the
+signature length and type are inferred from the transient [SigningPublicKey]_
+in the option.
+
 * When a packet contains both FROM_INCLUDED and SIGNATURE_INCLUDED (as in
   SYNCHRONIZE), the inference may be made directly.
 
@@ -184,11 +244,17 @@ References
 .. [Integer]
     {{ ctags_url('Integer') }}
 
+.. [OfflineSig]
+    {{ ctags_url('OfflineSignature') }}
+
 .. [Signature]
     {{ ctags_url('Signature') }}
 
 .. [SigningPrivateKey]
     {{ ctags_url('SigningPrivateKey') }}
 
+.. [SigningPublicKey]
+    {{ ctags_url('SigningPublicKey') }}
+
 .. [STREAMING]
     {{ site_url('docs/api/streaming', True) }}