lsd0012

commit a12631552ba92bbdb01f83e363094027aecb8138
parent 1beab45cfeeda132b387d97ad6b1625d603c978a
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Tue, 29 Jul 2025 13:27:55 +0200

sequence number and derivation clarifications

Diffstat:
M
draft-schanzen-cake.xml
 | 
19
++++++++++++-------

1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/draft-schanzen-cake.xml b/draft-schanzen-cake.xml
@@ -266,6 +266,7 @@ ss_e     |                                               |
         <ol>
           <li>(ss<sub>R</sub>,c<sub>R</sub>) &lt;- Encaps(pk<sub>R</sub>). Reciver KEM Challenge.</li>
           <li>r<sub>I</sub> &lt;- RandomUInt64(). Initiator nonce.</li>
+          <li>Encrypt pk<sub>I</sub> and svcinfo<sub>I</sub> using ETS (seq=0).</li>
         </ol>
         <t>
           R processes the InitiatorHello as follows:
@@ -286,9 +287,9 @@ ss_e     |                                               |
         </t>
         <ol>
           <li>r<sub>R</sub> &lt;- RandomUInt64(). Responder nonce.</li>
-          <li>Encrypt svcinfo_R and c<sub>I</sub> (Initiator KEM Challenge) using RHTS.</li>
+          <li>Encrypt svcinfo_R and c<sub>I</sub> (Initiator KEM Challenge) using RHTS (seq=0).</li>
           <li>Create finished<sub>R</sub> as per <xref target="cake_hs_proto"/>.</li>
-          <li>Encrypt finished<sub>R</sub> with RHTS.</li>
+          <li>Encrypt finished<sub>R</sub> with RHTS (seq=1).</li>
           <li>Optionally, R may now already send application data encrypted with RATS.</li>
         </ol>
         <t>
@@ -301,7 +302,7 @@ ss_e     |                                               |
           <li>ss<sub>I</sub> &lt;- Decaps(sk<sub>I</sub>,c<sub>I</sub>). Response to KEM Challenge</li>
           <li>Create finished<sub>R</sub> as per <xref target="cake_hs_proto"/> and check against decrypted payload.</li>
           <li>Create finished<sub>I</sub> as per <xref target="cake_hs_proto"/>.</li>
-          <li>Send finished<sub>I</sub> message encrypted with the key derived from IHTS to R</li>
+          <li>Send finished<sub>I</sub> message encrypted with the key derived from IHTS (seq=0) to R</li>
         </ol>
         <t>
           At this point we have a secure channel.
@@ -375,15 +376,19 @@ HKDF-Extract(ss_I,.) = Master Secret (MS)
             The KEM Challenges provide the underlying public key authentication mechanism.
           </t>
           <t>
-            When a traffic secret ([I,R][A,H]TS) is used to encrypt data, the respective
+            When a traffic secret ([I,R][A,H]TS or ETS) is used to encrypt data, the respective
             encryption key and starting nonce is generated as follows:
           </t>
         <figure anchor="figure_traffic_key_derivation" title="Traffic Key Generation.">
           <artwork name="" type="" align="left" alt=""><![CDATA[
-key = HKDF-Expand [I,R][A,H]TS, "key", 64)
-nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
+key = HKDF-Expand [I,R][A,H]TS, "key", 32)
+nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 24)
           ]]></artwork>
             </figure>
+         <t>
+            Notice that the per-message nonce is generated from the nonce above
+            as defined in <xref target="RFC8446" section="5.3"/> from the sequence number.
+         </t>
           <t>
             After a successful initial handshake, both initiator and responder may
             update the application traffic secrets ([A,I]ATS) and generate new keys.
@@ -519,7 +524,7 @@ nonce = HKDF-Expand ([I,R][A,H]TS, "iv", 12)
           with key and IV derived from the ETS.
           <!-- FIXME: Discuss IV. We may be able to use data from HKDF-Expand for that -->
         </t>
-        </section> 
+        </section>
         <section anchor="responder_hello" numbered="true" toc="default">
         <name>ResponderHello Message</name>
         <t>