From a2b9e4c8a7e2b16c656ec57d144de053c6fb7998 Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 3 Jun 2025 12:58:15 -0400 Subject: [PATCH] spec update --- i2p2www/spec/tunnel-creation-ecies.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/i2p2www/spec/tunnel-creation-ecies.rst b/i2p2www/spec/tunnel-creation-ecies.rst index 712cf486..a7788134 100644 --- a/i2p2www/spec/tunnel-creation-ecies.rst +++ b/i2p2www/spec/tunnel-creation-ecies.rst @@ -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.