forked from I2P_Developers/i2p.www
New proposal 157; add references to it in 152 and 256
This commit is contained in:
zzz
@@ -6,7 +6,7 @@ ECIES Tunnels
|
||||
:author: chisana, zzz, orignal
|
||||
:created: 2019-07-04
|
||||
:thread: http://zzz.i2p/topics/2737
|
||||
:lastupdated: 2020-09-23
|
||||
:lastupdated: 2020-10-09
|
||||
:status: Open
|
||||
:target: 0.9.51
|
||||
|
||||
@@ -84,6 +84,7 @@ Non-Goals
|
||||
- Shrinking tunnel build messages (requires all-ECIES hops and a new proposal)
|
||||
- Use of tunnel build options as defined in [Prop143]_, only required for small messages
|
||||
- Bidirectional tunnels - for that see [Prop119]_
|
||||
- Smaller tunnel build messages - for that see [Prop157]_
|
||||
|
||||
|
||||
Threat Model
|
||||
@@ -837,6 +838,9 @@ References
|
||||
.. [Prop156]
|
||||
{{ proposal_url('156') }}
|
||||
|
||||
.. [Prop157]
|
||||
{{ proposal_url('157') }}
|
||||
|
||||
.. [Tunnel-Creation]
|
||||
{{ spec_url('tunnel-creation') }}
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ ECIES Routers
|
||||
:author: zzz, orignal
|
||||
:created: 2020-09-01
|
||||
:thread: http://zzz.i2p/topics/2950
|
||||
:lastupdated: 2020-09-05
|
||||
:lastupdated: 2020-10-09
|
||||
:status: Open
|
||||
:target: 0.9.51
|
||||
|
||||
@@ -46,6 +46,7 @@ See [Prop152]_ for additional goals.
|
||||
- Maximize compatibility with current network
|
||||
- Do not require "flag day" upgrade to entire network
|
||||
- Gradual rollout to minimize risk
|
||||
- New, smaller tunnel build message
|
||||
|
||||
|
||||
Non-Goals
|
||||
@@ -54,7 +55,7 @@ Non-Goals
|
||||
See [Prop152]_ for additional non-goals.
|
||||
|
||||
- No requirement for dual-key routers
|
||||
- Complete redesign of tunnel build messages requiring a "flag day", for that see [Prop153]_
|
||||
- Layer encryption changes, for that see [Prop153]_
|
||||
|
||||
|
||||
Design
|
||||
@@ -92,9 +93,17 @@ are required to use ECIES instead of ElGamal.
|
||||
In addition, we will make improvements to the tunnel build messages
|
||||
to increase security.
|
||||
|
||||
In phase 1, we will change the format and encryption of the
|
||||
Build Request Record and Build Response Record for ECIES hops.
|
||||
These changes will be compatible with existing ElGamal routers.
|
||||
These changes are defined in proposal 152 [Prop152]_.
|
||||
Proposal 152 is preliminary and has not been fully reviewed.
|
||||
It will require significant corrections and cleanup.
|
||||
|
||||
In phase 2, we will add a new version of the
|
||||
Build Request Message, Build Reply Message,
|
||||
Build Request Record and Build Response Record.
|
||||
The size will be reduced for efficiency.
|
||||
These changes must be supported by all hops in a tunnel, and all hops must be ECIES.
|
||||
These changes are defined in proposal 157 [Prop157]_.
|
||||
|
||||
|
||||
|
||||
@@ -147,6 +156,7 @@ Tunnel Building: See [Prop152]_.
|
||||
|
||||
End-to-End Encryption: See [ECIES]_.
|
||||
|
||||
New Tunnel Build Message: See [Prop157]_.
|
||||
|
||||
|
||||
Justification
|
||||
@@ -255,6 +265,18 @@ Probably start rekeying mid-2021.
|
||||
Target release: TBD
|
||||
|
||||
|
||||
New Tunnel Build Message
|
||||
--------------------------
|
||||
|
||||
Implement and test the new Tunnel Build Message.
|
||||
Roll the support out in a release.
|
||||
Do additional testing, then enable it in the next release.
|
||||
|
||||
Probably mid-2021.
|
||||
|
||||
Target release: TBD
|
||||
|
||||
|
||||
ECIES for New Installs
|
||||
--------------------------
|
||||
|
||||
@@ -306,6 +328,9 @@ References
|
||||
.. [Prop154]
|
||||
{{ proposal_url('154') }}
|
||||
|
||||
.. [Prop157]
|
||||
{{ proposal_url('157') }}
|
||||
|
||||
.. [Tunnel-Creation]
|
||||
{{ spec_url('tunnel-creation') }}
|
||||
|
||||
|
||||
271
i2p2www/spec/proposals/157-new-tbm.rst
Normal file
271
i2p2www/spec/proposals/157-new-tbm.rst
Normal file
@@ -0,0 +1,271 @@
|
||||
========================================
|
||||
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 cryptographic primitives, protocols, and code.
|
||||
|
||||
This design minimizes risk.
|
||||
|
||||
|
||||
|
||||
|
||||
Implementation Notes
|
||||
=====================
|
||||
|
||||
|
||||
|
||||
|
||||
Issues
|
||||
======
|
||||
|
||||
- HKDF details
|
||||
- AES or ChaCha for reply encryption?
|
||||
- Should we do additional hiding from the paired OBEP or IBGW? Garlic?
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
The implementation, testing, and rollout will take several releases
|
||||
and approximately one year. The phases are as follows. Assignment of
|
||||
each phase to a particular release is TBD and depends on
|
||||
the pace of development.
|
||||
|
||||
Details of the implementation and migration may vary for
|
||||
each I2P implementation.
|
||||
|
||||
Tunnel creator must ensure that all hops are ECIES-X25519, AND are at least version TBD.
|
||||
The tunnel creator does NOT have to be ECIES-X25519; it can be ElGamal.
|
||||
However, if the creator is ElGamal, it reveals to the closest hop that it is the creator.
|
||||
So, in practice, these tunnels should only be created by ECIES routers.
|
||||
|
||||
It should NOT be necessary for the paired-tunnel OBEP or IBGW is ECIES or
|
||||
of any particular version, because they SHOULD support
|
||||
relaying of unknown message types.
|
||||
This should be verified in testing.
|
||||
|
||||
Phase 1: Implementation, not enabled by default
|
||||
|
||||
Phase 2 (next release): Enable by default
|
||||
|
||||
|
||||
Appendix
|
||||
==========
|
||||
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='text' %}
|
||||
Current 4-slot size: 4 * 528 + overhead = 3 tunnel messages
|
||||
|
||||
4-slot build message to fit in one tunnel message, ECIES-only:
|
||||
|
||||
1024
|
||||
- 21 fragment header
|
||||
----
|
||||
1003
|
||||
- 39 unfragmented instructions
|
||||
----
|
||||
964
|
||||
- 16 I2NP header
|
||||
----
|
||||
948
|
||||
- 1 number of slots
|
||||
----
|
||||
947
|
||||
/ 4 slots
|
||||
----
|
||||
236 New encrypted build record size (vs. 528 now)
|
||||
- 16 trunc. hash
|
||||
- 32 eph. key
|
||||
- 16 MAC
|
||||
----
|
||||
172 cleartext build record max (vs. 222 now)
|
||||
|
||||
Current build record cleartext size before unused padding: 193
|
||||
|
||||
Removal of full router hash and HKDF generation of keys/IVs would free up plenty of room for future options.
|
||||
If everything is HKDF, required cleartext space is about 82 bytes (without any options)
|
||||
|
||||
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [Common]
|
||||
{{ spec_url('common-structures') }}
|
||||
|
||||
.. [ECIES]
|
||||
{{ spec_url('ecies') }}
|
||||
|
||||
.. [I2NP]
|
||||
{{ spec_url('i2np') }}
|
||||
|
||||
.. [Prop123]
|
||||
{{ proposal_url('123') }}
|
||||
|
||||
.. [Prop144]
|
||||
{{ proposal_url('144') }}
|
||||
|
||||
.. [Prop145]
|
||||
{{ proposal_url('145') }}
|
||||
|
||||
.. [Prop152]
|
||||
{{ proposal_url('152') }}
|
||||
|
||||
.. [Prop153]
|
||||
{{ proposal_url('153') }}
|
||||
|
||||
.. [Prop154]
|
||||
{{ proposal_url('154') }}
|
||||
|
||||
.. [Prop156]
|
||||
{{ proposal_url('156') }}
|
||||
|
||||
.. [Tunnel-Creation]
|
||||
{{ spec_url('tunnel-creation') }}
|
||||
|
||||
Reference in New Issue
Block a user