diff --git a/i2p2www/spec/proposals/152-ecies-tunnels.rst b/i2p2www/spec/proposals/152-ecies-tunnels.rst
index 301b19ffb5db9259b6d1fdbefb0cda0b6e8abd87..c820a73e103446d1dcac1c368c821740fa9f6278 100644
--- a/i2p2www/spec/proposals/152-ecies-tunnels.rst
+++ b/i2p2www/spec/proposals/152-ecies-tunnels.rst
@@ -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') }}
diff --git a/i2p2www/spec/proposals/156-ecies-routers.rst b/i2p2www/spec/proposals/156-ecies-routers.rst
index ec38fd844ab5d2d645d057495ca12a83a796779b..9f4bfd3dd290aebc3b03212ebdba3f17de756adb 100644
--- a/i2p2www/spec/proposals/156-ecies-routers.rst
+++ b/i2p2www/spec/proposals/156-ecies-routers.rst
@@ -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') }}
diff --git a/i2p2www/spec/proposals/157-new-tbm.rst b/i2p2www/spec/proposals/157-new-tbm.rst
new file mode 100644
index 0000000000000000000000000000000000000000..f9eb2df5dd3ba65f2dbdb3ec771e5c2cbc83f3bc
--- /dev/null
+++ b/i2p2www/spec/proposals/157-new-tbm.rst
@@ -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') }}
+