======================================== Smaller Tunnel Build Messages ======================================== .. meta:: :author: zzz, orignal :created: 2020-10-09 :thread: http://zzz.i2p/topics/2957 :lastupdated: 2020-10-09 :status: Open :target: 0.9.51 .. contents:: Overview ======== Summary ------- The current size of the encrypted tunnel Build Request and Response records is 528. For typical Variable Tunnel Build and Variable Tunnel Build Reply messages, the total size is 2113 bytes. This message is fragmented into 1KB three tunnel messages for the reverse path. Changes to the 528-byte record format for ECIES-X25519 routers are specified in [Prop152]_. For a mix of ElGamal and ECIES-X25519 routers in a tunnel, the record size must remain 528 bytes. However, if all routers in a tunnel are ECIES-X25519, a new, smaller build record is possible, because ECIES-X25519 encryption has much less overhead than ElGamal. Smaller messages would save bandwidth. Also, if the messages could fit in a single tunnel message, the reverse path would be three times more efficient. This proposal defines new request and reply records and new Buid Request and Build Reply messages. Goals ----- See [Prop152]_ and [Prop156]_ for additional goals. - Smaller records and messages - Maintain sufficient space for future options, as in [Prop152]_ - Fit in one tunnel message for the reverse path - Support ECIES hops only - Maintain improvements implemented in [Prop152]_ - Maximize compatibility with current network - Do not require "flag day" upgrade to entire network - Gradual rollout to minimize risk - Reuse existing cryptographic primitives Non-Goals ----------- See [Prop156]_ for additional non-goals. - No requirement for mixed ElGamal/ECIES tunnels - Layer encryption changes, for that see [Prop153]_ - No speedups of crypto operations. It's assumed that ChaCha20 and AES are similar. Design ====== Records ------------------------------- See appendix for calculations. Encrypted request and reply records will be 236 bytes, compared to 528 bytes now. The plaintext request records will be either 160 or 172 bytes, compared to 222 bytes for ElGamal records, and 464 bytes for ECIES records as defined in [Prop152]_. The plaintext response records will be either 160 or 172 bytes, compared to 496 bytes for ElGamal records, and 512 bytes for ECIES records as defined in [Prop152]_. If we use AES for reply encryption, records must be a multiple of 16. If we use ChaCha20 (NOT ChaCha20/Poly1305), they can be 172 bytes. TBD. Request records will be made smaller by using HKDF to create the layer and reply keys, so they do not need to be explicitly included in the request. Tunnel Build Messages ----------------------- Both will be "variable" with a one-byte number of records field, as with the existing Variable messages. Build: Type 25 Reply: Type 26 Total length: 641 or 689 bytes Record Encryption ------------------ Request and reply record encryption: as defined in [Prop152]_. Reply record encryption for other slots: AES or ChaCha20? Specification ============= Request Record ----------------------- TBD Response Record ----------------------- TBD KDF ----------------------- TBD Tunnel Build Messages ----------------------- TBD Justification ============= This design maximizes reuse of existing cHTTP/1.1 200 OK X-Frame-Options: SAMEORIGIN Date: Wed, 23 Jul 2025 07:14:06 GMT Connection: close Cache-Control: public, max-age=21600, no-transform Content-Disposition: inline; filename="157-new-tbm.rst"; filename*=UTF-8''157-new-tbm.rst Last-Modified: Fri, 09 Oct 2020 15:06:13 GMT X-Content-Type-Options: nosniff Content-Length: 5937 Set-Cookie: i_like_gitea=1fb9b69a24bdb253; Path=/; HttpOnly; Secure; SameSite=Lax Set-Cookie: _csrf=8uqFpnwqe_GI47orKd7BHIPpbwI6MTc1MzI1NDg0NjcxNzg1NjczMA; Path=/; Max-Age=86400; HttpOnly; Secure; SameSite=Lax Access-Control-Expose-Headers: Content-Disposition Content-Type: text/plain; charset=utf-8 Etag: "f9eb2df5dd3ba65f2dbdb3ec771e5c2cbc83f3bc" X-Cache-Status: HIT X-Cache-Age: 0 ======================================== Smaller Tunnel Build Messages ======================================== .. meta:: :author: zzz, orignal :created: 2020-10-09 :thread: http://zzz.i2p/topics/2957 :lastupdated: 2020-10-09 :status: Open :target: 0.9.51 .. contents:: Overview ======== Summary ------- The current size of the encrypted tunnel Build Request and Response records is 528. For typical Variable Tunnel Build and Variable Tunnel Build Reply messages, the total size is 2113 bytes. This message is fragmented into 1KB three tunnel messages for the reverse path. Changes to the 528-byte record format for ECIES-X25519 routers are specified in [Prop152]_. For a mix of ElGamal and ECIES-X25519 routers in a tunnel, the record size must remain 528 bytes. However, if all routers in a tunnel are ECIES-X25519, a new, smaller build record is possible, because ECIES-X25519 encryption has much less overhead than ElGamal. Smaller messages would save bandwidth. Also, if the messages could fit in a single tunnel message, the reverse path would be three times more efficient. This proposal defines new request and reply records and new Buid Request and Build Reply messages. Goals ----- See [Prop152]_ and [Prop156]_ for additional goals. - Smaller records and messages - Maintain sufficient space for future options, as in [Prop152]_ - Fit in one tunnel message for the reverse path - Support ECIES hops only - Maintain improvements implemented in [Prop152]_ - Maximize compatibility with current network - Do not require "flag day" upgrade to entire network - Gradual rollout to minimize risk - Reuse existing cryptographic primitives Non-Goals ----------- See [Prop156]_ for additional non-goals. - No requirement for mixed ElGamal/ECIES tunnels - Layer