I2NP: update recommended number of build records

check in meeting logs

See merge request i2p-hackers/i2p.www!4

i2p2www/meetings/logs/293.log

@@ -0,0 +1,63 @@
+
+(04:00:50 PM) eyedeekay1: Hello zlatinb zzz mikalvmeeh eche|on, if you're all ready we'll start the meeting.
+(04:00:50 PM) eyedeekay1: 1) Hi
+(04:00:50 PM) eyedeekay1: 2) 0.9.47 release
+(04:00:50 PM) eyedeekay1: 3) Monthly meetings follow-up
+(04:00:50 PM) eyedeekay1: 4) Git update
+(04:01:38 PM) eyedeekay1: Hi everyone, first of all, I am sorry I did not notice that I got the date wrong in my announcement title.
+(04:02:38 PM) zzz: hi
+(04:02:58 PM) eyedeekay1: hi zzz
+(04:03:31 PM) zlatinb: hi
+(04:03:42 PM) eyedeekay1: Hi zlatinb
+(04:04:49 PM) eyedeekay1: OK so 2) the 0.9.47 release
+(04:05:27 PM) eyedeekay1: It does not look like I'm going to get rekeyOnIdle done in time for 0.9.47 either.
+(04:05:58 PM) eyedeekay1: What will be included are primarily updates to visual elements on my end.
+(04:06:19 PM) eyedeekay1: Anything from zzz or zlatinb on the 0.9.47 release topic?
+(04:06:43 PM) zzz: summary is at http://zzz.i2p/topics/2905
+(04:06:49 PM) zzz: tag freeze a week from tomorrow
+(04:06:53 PM) zzz: release in about 3 weeks
+(04:07:07 PM) zzz: diff is at about 18,500 lines which is pretty typical
+(04:07:23 PM) zzz: things are looking good. I have a few things to wrap up
+(04:07:40 PM) zzz: but I'm pretty confident we can stay on schedule
+(04:07:49 PM) zzz: EOT
+(04:08:08 PM) eyedeekay1: I saw quite a bit come in yesterday, have been trying to look at it incrementally as you push it. Really exciting to see your work. Thanks very much.
+(04:08:41 PM) zzz: that was just misc. stuff that had been sitting in my workspace for weeks, nothing to note really
+(04:09:42 PM) eyedeekay1: Well following along is educational nonetheless, I don't know where everything is, watching you work helps me recognize where different things happen
+(04:09:43 PM) zzz: just trying to get stuff cleaned up and pushed. sometimes I'll test something for months and months
+(04:10:28 PM) zzz: sure, reviewing other people's changes a great way to learn, and to catch mistakes, keep it up
+(04:10:39 PM) eyedeekay1: Will do
+(04:10:42 PM) eyedeekay1: If there's nothing else, I'll move on to 3) timeout 1m
+(04:12:40 PM) eyedeekay1: 2) Monthly Meeting Follow Up:
+(04:12:53 PM) eyedeekay1: This is the monthly meeting.
+(04:12:53 PM) eyedeekay1: I did not set up a WebIRC gateway, as I understand it would have been against our IRC rules to do so.
+(04:13:13 PM) eyedeekay1: I now have a copy of the meeting announcement rules and responsibility for those announcements has been clarified to me.
+(04:13:25 PM) eyedeekay1: The announcment for September 1, with the correct date this time, has been posted. No topics yet, please add them as you need them: http://zzz.i2p/topics/2931-meeting-tues-september-1-8pm-utc
+(04:14:55 PM) eyedeekay1: This will of course come shortly after the 0.9.47 release
+(04:15:45 PM) eyedeekay1: Anything on 2) from anyone else?
+(04:17:57 PM) eyedeekay1: 3) Git transition
+(04:18:34 PM) eyedeekay1: Git transition is finally getting underway, we have a plan and are beginning to execute upon it
+(04:19:08 PM) eyedeekay1: nextloop and I are making progress on getting the next few meaningful mtn branches mirrored over to github
+(04:19:27 PM) eyedeekay1: these are still read-only until the conclusion of their respective phases on the git migration, i.e. no pulls or MRs yet
+(04:20:04 PM) eyedeekay1: For a detailed description of these phases see: http://zzz.i2p/topics/2920-flipping-the-switch-on-git#10
+(04:20:42 PM) eyedeekay1: It would be helpful to nextloop and I if I gave nextloop permission to create repositories in the i2p namespace on github, and to write to the repositories he creates.
+(04:20:47 PM) zzz: good job on writing up the plan
+(04:21:24 PM) eyedeekay1: Thanks zzz, glad to finally have it in a usable state
+(04:22:17 PM) zzz: it's not perfect but it's 'usable' in that we can comment upon it
+(04:24:39 PM) eyedeekay1: The next thing that we'll be moving is the web site, which is nice because it's quite simple and doesn't have anything that depends on it, that should be happening this week
+(04:25:26 PM) eyedeekay1: But re: nextloop, I'd like to know that it met with broad approval to grant him this permission to create/write to github repos for us?
+(04:25:54 PM) zzz: ok. awaiting your edit to the plan/schedule to deconflict it with the .47 release
+(04:26:25 PM) eyedeekay1: Ack, got it open in my editor :)
+(04:26:48 PM) zzz: You'll have to ask the people that are currently github admins, who aren't here, and I'm not a member of
+(04:27:39 PM) eyedeekay1: Thusfar this proposal meets with their approval, although I do still have one non-responder.
+(04:29:05 PM) zzz: it's fine with me as long as you two have a reliable communication method and backup. I don't think we need any more unresponsive admins :)
+(04:29:53 PM) eyedeekay1: I think we can manage that
+(04:30:06 PM) eyedeekay1: So nextloop with get github privs
+(04:31:40 PM) zzz: long-unresponsive people with a lot of privileges might be good for a worst-case hit-by-bus backup, but it's also a potential security risk, so that needs to be managed
+(04:33:12 PM) eyedeekay1: Yeah
+(04:33:20 PM) eyedeekay1: If there's anything else we can deal with here on 3) then I think now, otherwise we'll see the revised plan on the zzz.i2p thread probably within the next day.
+(04:33:45 PM) zzz: super
+(04:34:18 PM) mikalvmeeh: (I'm halfy here, missed out on the hi)
+(04:34:56 PM) eyedeekay1: Well we've made it through the planned topics, does anyone have anything else?
+(04:36:43 PM) eyedeekay1: timeout 1m
+(04:38:51 PM) eyedeekay1: *bafs* All right that closes this meeting. Please remember September 1, the next scheduled meeting at this same time, 8PM UTC
+(04:39:12 PM) eyedeekay1: Thank you everyone for coming

i2p2www/meetings/logs/293.rst

@@ -0,0 +1,11 @@
+I2P dev meeting, August 4, 2020 @ 20:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+zlatinb,
+zzz

i2p2www/meetings/logs/295.log

@@ -0,0 +1,76 @@
+(04:00:04 PM) eyedeekay: Hello everyone and welcome to the October I2P Community Meeting.
+(04:00:04 PM) eyedeekay: On the agenda for today is:
+(04:00:04 PM) eyedeekay: 1) Hi
+(04:00:04 PM) eyedeekay: 2) 0.9.48 release (zzz)
+(04:00:04 PM) eyedeekay: 3) Git Progress Update (idk)
+(04:00:04 PM) eyedeekay: 4) UI Team / OTF Update (idk)
+(04:00:04 PM) eyedeekay: 5) Android update (idk)
+(04:00:17 PM) eyedeekay: Hi everyone, who all is here?
+(04:00:25 PM) orignal: hi
+(04:00:29 PM) eyedeekay: Hi orignal
+(04:00:33 PM) zzz: hello
+(04:00:39 PM) eyedeekay: Hello zzz
+(04:01:14 PM) eyedeekay: Anyone else?
+(04:01:53 PM) eyedeekay: OK moving on to 2
+(04:02:14 PM) eyedeekay: I've seen zzz doing quite a lot lately, for myself, My only plan for inside the router for the 0.9.48 release is rekeyOnIdle. Overwhelmingly my plans for this release will have to do with completing the next 2 phases of the git migration, and with changes to i2p.www which I will detail in 4).
+(04:02:45 PM) zzz: we're I think, 5 weeks into the cycle. things are going well
+(04:03:14 PM) zzz: orignal and I working on improving tunnel building (proposal 152), and have started to land some of that code
+(04:03:29 PM) zzz: SSU2 research is going slowly, and certainly won't have any code in .48
+(04:03:50 PM) zzz: 7500 lines of diff in the release so far, pretty typical
+(04:04:08 PM) zzz: target is mid-to-late Novemeber for the .48 release, we'll probably set a date soon
+(04:04:18 PM) zzz: EOT
+(04:04:44 PM) eyedeekay: Thanks very much zzz
+(04:05:14 PM) eyedeekay: Thanks also for the frequent forum updates, it makes some of your progress easier to digest and explain to others
+(04:05:43 PM) eyedeekay: On to 3)
+(04:06:03 PM) eyedeekay: We are in phase three of the git migration.
+(04:06:08 PM) eyedeekay: i2p.www is migrated. It had the most dependence on mtn of all the projects.
+(04:06:14 PM) eyedeekay: i2p.firefox is also migrated.
+(04:06:22 PM) eyedeekay: We are going to have i2p.newsxml migrated on Thursday evening, at 18.00 UTC.
+(04:06:32 PM) eyedeekay: After that I will be getting it touch with zzz about migrating zzzot or snark-rpc next.
+(04:06:37 PM) eyedeekay: Repositories where mtn syncing has been disabled are kept in sync between github and gitlab.
+(04:06:44 PM) eyedeekay: We are on a steady path now, as soon as one repo is migrated, we start the next.
+(04:06:58 PM) eyedeekay: EOT
+(04:08:23 PM) eyedeekay: Any questions on Git?
+(04:09:06 PM) eyedeekay: Timeout 1m
+(04:10:16 PM) eyedeekay: OK on to 4)
+(04:11:20 PM) eyedeekay: The design firm hired by the OTF created a revised style guide. The new guide is somewhat more "flexible" than the old one, while also encouraging us toward a level of internal consistency.
+(04:11:20 PM) eyedeekay: It is located here: https://uracreative.github.io/i2p-styleguide/. A post requesting comments from the community on the style recommendations, and which ones to implement, and how, is here: http://i2pforum.i2p/viewtopic.php?f=21&t=986&sid=bbca7a971055b8449737ba038ebbfa49
+(04:11:20 PM) eyedeekay: The difficulty of implementing the design recommendations results from the fact that changes implemented partially tend to be visually unappealing, for example see the recent icon issue in I2PSnark.
+(04:12:26 PM) eyedeekay: However, this only comprises 1/2 of the advice we recieved
+(04:13:01 PM) eyedeekay: The most significant improvement we could make identified by the programs paid for by the OTF entailing the work of Ura Design and Simsec was an overall problem with onboarding new participants of all types.
+(04:13:16 PM) eyedeekay: We consider this the priority. The early phases of improving it will mostly occur in i2p.www
+(04:13:19 PM) eyedeekay: One of the most common questions that has been asked is "Who is I2P for."
+(04:13:42 PM) eyedeekay: The design/usability people are obviously not the only people who have asked that question
+(04:13:52 PM) eyedeekay: So we identified "types" of participants, including users, service operators, app developers, router developers.
+(04:13:52 PM) eyedeekay: We had a lot of answers to that question, but one of the most common patterns in our answers was that it's much easier to say who I2P "Applications" are for.
+(04:14:07 PM) eyedeekay: So we want to get people using applications faster and more easily. Changing these paths is what has been referred to as "Information Architecture"
+(04:14:07 PM) eyedeekay: Accomplishing this will entail producing:
+(04:14:07 PM) eyedeekay:  - Installation instructions on Windows that include installing a Java version which is known to work with I2P.
+(04:14:07 PM) eyedeekay:  - Pages on the site explaining the bundled apps that come with the Java I2P router.
+(04:14:07 PM) eyedeekay:  - Inclusion of I2P in Private Browsing webextension into the Windows I2P profile bundle
+(04:14:07 PM) eyedeekay:  - An IRC client recommendation and guide.
+(04:14:07 PM) eyedeekay:  - First-class service hosting guides(Like the one for Gitlab), for new operators, including a re-write of the Reseed Service Guide. Also planned are NextCloud and IRC hosting guides.
+(04:14:07 PM) eyedeekay:  - Re-organization of the home page and the top-level navigation menu around the users.
+(04:14:44 PM) eyedeekay: Sorry for basically going long-form with it, but take your time please, I wanted to make sure I gave a substantial update
+(04:17:14 PM) eyedeekay: EOT. Any questions?
+(04:17:26 PM) zzz: is the OTF work complete? when did they finish? when did the revised style guide become available?
+(04:19:20 PM) eyedeekay: The OTF paid the design firm, and they finished last month. Just a moment while I check the history
+(04:19:56 PM) eyedeekay: August 8th
+(04:20:10 PM) zzz: what I'm getting at is, how can we fix our processes so that the status and results of funded work are actually communicated to the community in a timely manner?
+(04:21:07 PM) eyedeekay: Usually the solution to that is me keeping in touch with someone. In this case, that someone probably ought to take the form of me doing periodic updates to i2pforums.i2p
+(04:22:38 PM) zzz: ok. it's just very odd that a funded project that results in advice for developers never actually got communicated to developers for two months
+(04:23:06 PM) zzz: so if we ever go around again on this, that will be a discussion for process improvement
+(04:23:14 PM) zzz: thanks for the report
+(04:23:35 PM) eyedeekay: Just doing my best to solve problems :)
+(04:23:39 PM) eyedeekay: Which brings us to 5)
+(04:24:46 PM) eyedeekay: I am now the administrator of all the servers where we offer Android apps for download, since the other admin was unresponsive.
+(04:24:51 PM) eyedeekay: I was eventually able to contact the other admin, and he has agreed to act as a back up.
+(04:24:59 PM) eyedeekay: The plan going forward is for me to upload to GPlay and our F-Droid on the same day as Debian packages are released.
+(04:25:03 PM) eyedeekay: This means that our F-Droid will be available on the same day that Debian packages are uploaded. GPlay will still be delayed by what seems like 1-6 days, not much I can do for that.
+(04:25:29 PM) eyedeekay: This also means that I'm the admin of download.i2p2.de now, so I can fix that too. I can basically fix everything but trac.
+(04:27:09 PM) eyedeekay: EOT
+(04:28:15 PM) eyedeekay: Oh that's what I forgot. I am *not* in charge of the upload to the F-Droid community repository. That's nextloop still.
+(04:30:21 PM) eyedeekay: Does anyone have anything they wish to add, want to cover for the meeting, or any questions about anything we've covered so far?
+(04:31:02 PM) eyedeekay: timeout 1m
+(04:31:13 PM) zzz: reminder (again) - put the august meeting on the website
+(04:32:00 PM) eyedeekay: I thought I had? OK, will add it right after we're done

i2p2www/meetings/logs/295.rst

@@ -0,0 +1,11 @@
+I2P dev meeting, October 6, 2020 @ 20:00 UTC
+============================================
+
+Quick recap
+-----------
+
+* **Present:**
+
+eyedeekay,
+orignal,
+zzz

i2p2www/spec/i2np.rst

@@ -3,8 +3,8 @@ I2NP Specification
 ==================
 .. meta::
     :category: Protocols
-    :lastupdated: 2020-06
-    :accuratefor: 0.9.46
+    :lastupdated: 2020-10
+    :accuratefor: 0.9.48
 
 .. contents::
 
@@ -1476,7 +1476,7 @@ Notes
 * The I2NP message ID for this message must be set according to the tunnel
   creation specification.
 
-* Typical number of records in today's network is 5.
+* Typical number of records in today's network is 4, for a total size of 2113.
 
 .. _msg-VariableTunnelBuildReply:
 
@@ -1503,7 +1503,7 @@ Notes
 * The I2NP message ID for this message must be set according to the tunnel
   creation specification.
 
-* Typical number of records in today's network is 5.
+* Typical number of records in today's network is 4, for a total size of 2113.
 
 
 References

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') }}
 

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') }}
 

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') }}
+