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

spec update

Browse Source
This commit is contained in:
zzz
2025-06-03 12:58:15 -04:00
parent 1e70151059
commit a2b9e4c8a7
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
i2p2www/spec/tunnel-creation-ecies.rst
View File

@ -3,8 +3,8 @@ ECIES-X25519 Tunnel Creation
=============================
.. meta::
:category: Protocols
:lastupdated: 2025-03
:accuratefor: 0.9.65
:lastupdated: 2025-06
:accuratefor: 0.9.66
.. contents::
@ -913,10 +913,9 @@ The recommended minimum number of build records is 4.
If there are more build records than hops, "fake" records must be added,
containing random or implementation-specific data.
For inbound tunnel builds, there must always be one "fake" record for the
originating router, with the correct 16-byte hash prefix, otherwise
originating router, with the correct 16-byte hash prefix
and a real X25519 ephemeral key, otherwise
the closest hop will know that the next hop is the originator.
The MSB of the ephemeral key (data[47] & 0x80) must also be cleared
so it looks like a real X25519 public key.
The remainder of the "fake" record may be random data, or may encrypted in any format
for the originator to send data to itself about the build,
@ -926,6 +925,7 @@ Originators of inbound tunnels must use some method to validate
that their "fake" record has not been modified by the previous hop,
as this may also be used for deanonimization.
The orignator may store and verify a checksum of the record,
or include the checksum in the record,
or use an AEAD encryption/decryption function, implementation-dependent.
If the 16-byte hash prefix or other build record contents were
modified, the router must discard the tunnel.