commit 14942d7ab3903d15be0cb101cebab1c6f3c08664
parent db761dab3d7f38bf1d9e09cdfd5033f4c33529b7
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 12 Nov 2024 12:35:40 +0100
reorganize, more on encryption
Diffstat:
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/draft-schanzen-cake.xml b/draft-schanzen-cake.xml
@@ -122,14 +122,14 @@
<dt>ES</dt> <dd>Early Secret Key</dd>
<dt>IHTS</dt> <dd>Initiator Handshake Secret Key</dd>
<dt>RHTS</dt> <dd>Receiver Handshake Secret Key</dd>
- <dt>Foo...Bar</dt> <dd>means the transcript of received/send messages from Foo until Bar</dd>
+ <dt>Foo...Bar</dt> <dd>means the transcript of received/send messages from Foo until Bar. Note that the transcript refers to what is seen on the wire (i.e. potentially encryption) but as shorthand, we only refer to the plaintext message.</dd>
<dt>Enc/Dec</dt> <dd>This refers to <xref target="RFC8439"/>, the ChaCha20-Poly1305 Authenticated Encryption with Associated Data (AEAD) construction.</dd>
</dl>
</section>
<section anchor="notation" numbered="true" toc="default">
<name>Notation</name>
<t>
- We use the notation and terminology of <xref target="RFC9180"/> throughout
+ We use the notation and terminology of <xref target="RFC8439"/> and <xref target="RFC9180"/> throughout
this document.
</t>
</section>
@@ -216,7 +216,7 @@ MS | |
]]></artwork>
</figure>
<t>
- The Initiator creates the first message containing InitiatorHello and the encrypted tuple (pk<sub>I</sub>,ServicesInfo) according to <xref target="figure_swimlane"/> and <xref target="figure_key_schedule"/> using:
+ The Initiator creates the first message containing InitiatorHello and the encrypted tuple (pk<sub>I</sub>,ServicesInfo)*ETS according to <xref target="figure_swimlane"/> and <xref target="figure_key_schedule"/> using:
</t>
<ol>
<li>(ss<sub>R</sub>,c<sub>R</sub>) <- Encaps(pk<sub>R</sub>)</li>
@@ -231,11 +231,11 @@ MS | |
</t>
<ol>
<li>ReceiverHello <- (c<sub>R</sub>,r<sub>I</sub>)</li>
- <li>The initiators's pk<sub>I</sub> and ServicesInfo encrypted using ETS.</li>
+ <li>(pk<sub>I</sub>,ServicesInfo)*ETS.</li>
</ol>
<t>
R receives the first message, and processes it as defined in the following.
- The encryption key ETS to decrypt the encrypted tuple (pk<sub>I</sub>,<tt>ServicesInfo</tt>), the Handshake and Master Secrets are generated according to <xref target="figure_key_schedule"/> using:
+ The encryption key ETS to decrypt the encrypted tuple (pk<sub>I</sub>,<tt>ServicesInfo</tt>), the Handshake and Master Secrets are generated according to <xref target="figure_key_schedule"/>.
The secrets can also be generated as-needed and not necessarily all at once.
Note that IATS cannot be derived (yet) at this point.
</t>
@@ -243,16 +243,17 @@ MS | |
<li>Verify that the message type is TBD</li>
<li>(ss<sub>R</sub>,c<sub>R</sub>) <- Decaps(sk<sub>R</sub>, c<sub>R</sub>)</li>
<li>(ss<sub>e</sub>,c<sub>e</sub>) <- Encaps(pk<sub>e</sub>)</li>
+ <li>Generate ETS from <xref target="key_schedule"/> and decrypt pk<sub>I</sub>.</li>
<li>(ss<sub>I</sub>,c<sub>I</sub>) <- Encaps(pk<sub>I</sub>)</li>
+ <li>Generate RHTS and RATS from <xref target="key_schedule"/>.</li>
</ol>
<t>
R sends to I:
</t>
<ol>
<li>ReceiverHello <- (c<sub>e</sub>,r<sub>R</sub>)</li>
- <li>The receiver's ServicesInfo encrypted using RTHS.</li>
- <li>c<sub>I</sub> encrypted with RTHS.</li>
- <li>ReceiverFinished encrypted with RHTS.</li>
+ <li>ReceiverFinished <- HMAC(fk<sub>I</sub>, InitiatorHello...ReceiverKemCiphertext)</li>
+ <li>(ServicesInfo, c<sub>I</sub>, ReceiverFinished)*RHTS.</li>
<li>Optionally, R may already send application data encrypted with RATS.</li>
</ol>
<t>
@@ -260,11 +261,19 @@ MS | |
</t>
<ol>
<li>Verify that the message type is TBD</li>
- <li>Setup remaining keys using ss<sub>e</sub> <- Decaps(sk<sub>e</sub>,c<sub>e</sub>) and ss<sub>I</sub> <- Decaps(sk<sub>I</sub>,c<sub>I</sub>).</li>
- <li>RF <- Dec(RHTS, ReceiverFinished)</li>
+ <li>ss<sub>e</sub> <- Decaps(sk<sub>e</sub>,c<sub>e</sub>)</li>
+ <li>Generate IHTS and RHTS from <xref target="key_schedule"/> and decrypt ServicesInfo, c<sub>I</sub> and ReceiverFinished.</li>
+ <li>ss<sub>I</sub> <- Decaps(sk<sub>I</sub>,c<sub>I</sub>).</li>
<li>fk<sub>R</sub> <- HKDF-Expand(MS, "r finished", NULL)</li>
- <li>assert HMAC(fk<sub>R</sub>, InitiatorHello...ReceiverKemCiphertext) == RF</li>
- <li>Send InitiatorFinished</li>
+ <li>assert HMAC(fk<sub>R</sub>, InitiatorHello...ReceiverKemCiphertext) == ReceiverFinished</li>
+ <li>fk<sub>I</sub> <- HKDF-Expand(MS, "i finished", NULL)</li>
+ <li>IteratorFinished <- HMAC(fk<sub>I</sub>, InitiatorHello...ReceiverFinished)</li>
+ </ol>
+ <t>
+ I sends to R:
+ </t>
+ <ol>
+ <li>(InitiatorFinished)*IHTS</li>
</ol>
<t>
At this point we have a secure channel.
@@ -437,6 +446,8 @@ ss_I -> HKDF-Extract = Master Secret (MS)
With ChaCha20, we should increment the nonce.
We could probably increment both. Incrementing may allow us to derive a starting nonce from
the key schedule.
+ We can get away with ChaCha20 (TLS, IETF) and its 32-bit internal counter because our
+ messages are <= 2<sup>16</sup>-1 bytes and the counter cannot overflow.
</t>
<t>
The Initiator/Receiver selection logic may require a timed fallback: The designates Initiator may never initiate (NAT, already has sufficient connections, learns about receiver later than receiver about initiator etc.).
