From 4bc9e8ac42bae30aef2f9e06059ec933f8509745 Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 26 Apr 2025 07:47:12 -0400 Subject: [PATCH] ratchet updates --- i2p2www/spec/ecies.rst | 96 +++++++++++++++++++++++++++++++++++++++++- i2p2www/spec/ntcp2.rst | 14 +++--- 2 files changed, 101 insertions(+), 9 deletions(-) diff --git a/i2p2www/spec/ecies.rst b/i2p2www/spec/ecies.rst index c191e80e..75f1f518 100644 --- a/i2p2www/spec/ecies.rst +++ b/i2p2www/spec/ecies.rst @@ -182,6 +182,44 @@ Bound sessions are similar to the Noise IK pattern. {% endhighlight %} +Security Properties +``````````````````` + +Using Noise terminology, the establishment and data sequence is as follows: +(Payload Security Properties from [Noise]_ ) + +.. raw:: html + + {% highlight lang='text' %} +IK(s, rs): Authentication Confidentiality + <- s + ... + -> e, es, s, ss 1 2 + <- e, ee, se 2 4 + -> 2 5 + <- 2 5 +{% endhighlight %} + + +Differences From XK +``````````````````` +IK handshakes have several differences from XK handshakes used +in [NTCP2]_ and [SSU2]_. + +- Four total DH operations compared to three for XK +- Sender authentication in first message: The payload is authenticated + as belonging to the owner of the sender's public key, although + the key could have been compromised (Authentication 1) + XK requires another round trip before Alice is authenticated. +- Full forward secrecy (Confidentiality 5) after the second message. + Bob may send a payload immediately after the second message with + full forward secrecy. + XK requires another round trip for full forward secrecy. + +In summary, IK allows 1-RTT delivery of the response payload from Bob to Alice +with full forward secrecy, however the request payload is not forward-secret. + + Sessions -------- @@ -3018,7 +3056,7 @@ If the timer does fire, send an empty payload with the NSR or ES. -Protocol-layer Responses +Ratchet-layer Responses ```````````````````````` Initial implementations rely on bidirectional traffic at the higher layers. @@ -3031,7 +3069,7 @@ such that there is no higher-layer traffic to generate a timely response. Receipt of NS and NSR messages require a response; receipt of ACK Request and Next Key blocks also require a response. -A sophisticated implementation may start a timer when one of these +Implementations should start a timer when one of these messages is received which requires a response, and generate an "empty" (no Garlic Clove block) response at the ECIES layer @@ -3042,6 +3080,51 @@ responses to NS and NSR messages, to shift the traffic to the efficient ES messages as soon as possible. +NS Binding For NSR +`````````````````` + +At the ratchet layer, as Bob, Alice is only known by static key. +The NS message is authenticated ([Noise]_ IK sender authentication 1). +However, this is not sufficient for the ratchet layer to be able to send anything +to Alice, as network routing requires a full Destination. + +Before the NSR may be sent, Alice's full Destination must be discovered either +by the ratchet layer or a higher-layer repliable protocol, +either repliable [Datagrams]_ or [Streaming]_. +After finding the Leaseset for that Destination, that Leaseset +will contain the same static key as contained in the NS. + +Typically, the higher layer will respond, forcing a network database +lookup of Alice's Leaseset by Alice's Destination Hash. +That Leaseset will almost always be found locally, because the +NS contained a Garlic Clove block, containing a Database Store message, +containing Alice's Leaseset. + +For Bob to be prepared to send a ratchet-layer NSR, and to bind +the pending session to Alice's Destination, Bob should +"capture" the Destination while processing the NS payload. +If a Database Store message is found containing a Leaseset +with a key matching the static key in the NS, +the pending session is now bound to that Destination, +and Bob knows where to send any NSR if the response timer expires. +This is the recommended implementation. + +An alternative design is to maintain a cache or database +where the static key is mapped to a Destination. +The security and practicality of this approach +is a topic for further study. + +Neither this specification nor others strictly require that +every NS contains Alice's Leaseset. +However, in practice, it should. +The recommended ES tagset sender timeout (8 minutes) +is shorter than the maximum Leaseset timeout (10 minutes), +so there could be a small window where the previous session +has expired, Alice thinks that Bob +still has her valid Leaseset, and does not send a new Leaseset +with the new NS. This is a topic for further study. + + Multiple NS Messages ```````````````````` @@ -3168,6 +3251,9 @@ References .. [CRYPTO-ELG] {{ site_url('docs/how/cryptography', True) }}#elgamal +.. [Datagrams] + {{ spec_url('datagrams') }} + .. [Elligator2] https://elligator.cr.yp.to/elligator-20130828.pdf https://www.imperialviolet.org/2013/12/25/elligator.html @@ -3239,6 +3325,12 @@ References .. [SSU] {{ site_url('docs/transport/ssu', True) }} +.. [SSU2] + {{ spec_url('ssu2') }} + +.. [Streaming] + {{ spec_url('streaming') }} + .. [STS] Diffie, W.; van Oorschot P. C.; Wiener M. J., Authentication and Authenticated Key Exchanges diff --git a/i2p2www/spec/ntcp2.rst b/i2p2www/spec/ntcp2.rst index eca46bda..f25d49c0 100644 --- a/i2p2www/spec/ntcp2.rst +++ b/i2p2www/spec/ntcp2.rst @@ -3,8 +3,8 @@ NTCP 2 ====== .. meta:: :category: Transports - :lastupdated: 2024-01 - :accuratefor: 0.9.61 + :lastupdated: 2025-04 + :accuratefor: 0.9.66 .. contents:: @@ -110,7 +110,7 @@ Alice Bob {% endhighlight %} Using Noise terminology, the establishment and data sequence is as follows: -(Payload Security Properties) +(Payload Security Properties from [Noise]_ ) .. raw:: html @@ -368,7 +368,7 @@ Noise content: Alice's ephemeral key X Noise payload: 16 byte option block Non-noise payload: Random padding -(Payload Security Properties) +(Payload Security Properties from [Noise]_ ) .. raw:: html @@ -703,7 +703,7 @@ Noise content: Bob's ephemeral key Y Noise payload: 16 byte option block Non-noise payload: Random padding -(Payload Security Properties) +(Payload Security Properties from [Noise]_ ) .. raw:: html @@ -992,7 +992,7 @@ Noise content: Alice's static key Noise payload: Alice's RouterInfo and random padding Non-noise payload: none -(Payload Security Properties) +(Payload Security Properties from [Noise]_ ) .. raw:: html @@ -1267,7 +1267,7 @@ Types include date/time, I2NP message, options, termination, and padding. Note: Bob may, but is not required, to send his RouterInfo to Alice as his first message to Alice in the data phase. -(Payload Security Properties) +(Payload Security Properties from [Noise]_ ) .. raw:: html