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

Streaming changes for proposal 123

Browse Source 
Streaming versions chart
I2CP fixes for CreateLeaseSet2 Message
Start of blinding changes in proposal 123
This commit is contained in:
zzz
2019-02-03 13:15:18 +00:00
parent 039c4a4c0b
commit 0a3a6238df
4 changed files with 105 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
i2p2www/pages/site/docs/protocol/i2cp.html
View File

@ -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>

21
i2p2www/spec/i2cp.rst
View File

@ -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
(by Destination or transient signing key).
Not present for MetaLeaseSet.
5. [PrivateKey]_ list.
4. [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:

51
i2p2www/spec/proposals/123-new-netdb-entries.rst
View File

@ -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,
otherwise 0
Bits 3-1: Authentication scheme, only if bit 1 is set to 1 for per-client, 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
trapdoor function, and it's defined in terms of iterated point
addition. See the Ed25519 paper [ED25519-REFS]_ for a fairly
clear writeup.)
We do not use Tor's rend-spec-v3.txt appendix A.2 [TOR-REND-SPEC-V3]_,
which has similar design goals, because its blinded public keys
may be off the prime-order subgroup, with unknown security implications.
Copied from Tor rend-spec-v3.txt appendix A.2
which has similar design goals [TOR-REND-SPEC-V3]_.
Changes for I2P TODO
The RedDSA signatures are over the Ed25519 curve, using SHA-512 for the hash.
::
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.
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.
is not present in LS2.
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

74
i2p2www/spec/streaming.rst
View File

@ -3,8 +3,8 @@ Streaming Library Specification
===============================
.. meta::
:category: Protocols
:lastupdated: June 2015
:accuratefor: 0.9.20
:lastupdated: February 2019
: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) }}