kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Prop. 152 updates

Browse Source
This commit is contained in:
zzz
2020-10-25 07:53:49 -04:00
parent f10920fff4
commit 984c7e1510
1 changed files with 11 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
i2p2www/spec/proposals/152-ecies-tunnels.rst
View File

@@ -6,7 +6,7 @@ ECIES Tunnels
:author: chisana, zzz, orignal
:created: 2019-07-04
:thread: http://zzz.i2p/topics/2737
:lastupdated: 2020-10-24
:lastupdated: 2020-10-25
:status: Open
:target: 0.9.51
@@ -31,6 +31,9 @@ follow this spec for creating tunnels containing ECIES hops.
This proposal specifies changes needed for ECIES-X25519 Tunnel Building.
For an overview of all changes required for ECIES routers, see proposal 156 [Prop156]_.
This proposal maintains the same size for tunnel build records,
as required for compatibility. Smaller build records and messages will be
implemented later - see [Prop157]_.
Cryptographic Primitives
@@ -384,6 +387,9 @@ Bit 7 indicates that the hop will be an inbound gateway (IBGW). Bit 6
indicates that the hop will be an outbound endpoint (OBEP). If neither bit is
set, the hop will be an intermediate participant. Both cannot be set at once.
The request exipration is for future variable tunnel duration.
For now, the only supported value is 600 (10 minutes).
The tunnel build options is a Mapping structure as defined in [Common]_.
This is for future use. No options are currently defined.
If the Mapping structure is empty, this is two bytes 0x00 0x00.
@@ -769,35 +775,15 @@ This design minimizes risk.
Implementation Notes
=====================
* Older routers do not check the encryption type of the hop and will send ElGamal-encrypted
records. Some recent routers are buggy and will send various types of malformed records.
Implementers should detect and reject these records prior to the DH operation
if possible, to reduce CPU usage.
Issues
======
* Is an HKDF required for the keys, what's the advantage of doing that vs.
just including them in the build record as before?
* Make KDFs be similar to those in Noise (NTCP2) and Ratchet
* HKDF output no more than 64 bytes preferred
* In the current Java implementation, the full router hash field in the build
request record at bytes 4-35 is not checked and does not appear to be necessary.
* Each record is CBC encrypted with the same AES reply key and IV, as with the current design.
Is this a problem? Can it be fixed?
* In the current Java implementation, the originator leaves one record empty
for itself. Thus a message of n records can only build a tunnel of n-1 hops.
This is necessary for inbound tunnels (where the next-to-last hop
can see the hash prefix for the next hop), but not for outbound tunnels.
However, if the build message length is different for inbound and outbound
tunnels, this would allow hops to determine which direction the tunnel was.
* Should we define new, smaller VTBM/VTBRM I2NP messages for all-ECIES tunnels
now instead of waiting for the rollout?
Migration