commit 6ccfe9c9b60940920dc6ce5df5e45c7a8f8573eb
parent e3ad2f3ef954dff16eafade16344cd9808d238b7
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 13 Nov 2024 09:02:05 +0100
keyupdate
Diffstat:
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/draft-schanzen-cake.xml b/draft-schanzen-cake.xml
@@ -282,7 +282,7 @@ MS | |
<t>
The key schedule is very similar to <xref target="RFC8446"/> Section 7.1:
</t>
- <figure anchor="figure_key_schedule" title="The Key Schedule.">
+ <figure anchor="figure_key_schedule" title="The Key Schedule.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0
|
@@ -313,20 +313,37 @@ ss_I -> HKDF-Extract = Master Secret (MS)
|
+-----> HKDF-Expand(., "i ap traffic",
| InitiatorHello...ReceiverFinished)
- | = IATS
+ | = IATS_0
|
+-----> HKDF-Expand(., "r ap traffic",
InitiatorHello...ReceiverFinished)
- = RATS
+ = RATS_0
]]></artwork>
</figure>
<t>
- SHA-512 is used as the underlying hash function for HKDF.
- Since we only require 32 byte encryption keys, the remaining
- 32 byte output of the HKDF-Expand is used as nonce.
- For each re-use of the key this nonce <bcp14>MUST</bcp14> be
- incremented.
+ When a traffic secret (*TS) 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)
+ ]]></artwork>
+ </figure>
+ <t>
+ After a successful initial handshake, both initiator and receiver may
+ update the application traffic secrets ([A,I]ATS) and generate new keys.
+ Let [I,R]ATS<sub>0</sub> be the initial secrets with index 0.
+ The next secret is derived as:
+ </t>
+ <figure anchor="figure_traffic_key_derivation_next" title="Traffic Secret Update.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+[I,R]ATS_N+1 = HKDF-Expand ([I,R]ATS_N, "traffic_upd", secret_len)
+ ]]></artwork>
+ </figure>
+ <t>
+ When a peer wants to update keys, it sends a key update message <xref target="key_update_msg"/>.
+ </t>
</section>
<section anchor="wire_formats" numbered="true" toc="default">
<name>Wire Formats</name>
@@ -454,6 +471,29 @@ ss_I -> HKDF-Extract = Master Secret (MS)
preceeding the EncryptedMessage header.
</t>
</section>
+ <section anchor="key_update_msg" numbered="true" toc="default">
+ <name>KeyUpdate</name>
+ <t>
+ The KeyUpdate message is a simple MessageHeader with type <tt>CORE_KEY_UPDATE</tt>
+ followed by a UpdateRequested indicator.
+ It is always a payload inside an EncryptedMessage.
+ This means that for every received EncryptedMessage where the payload is
+ the size of a KeyUpdate, the peer <bcp14>MUST</bcp14> check if this is
+ a KeyUpdate.
+ A KeyUpdate message indicates that the sender has switched its traffic secrets
+ according to the key schedule in <xref target="key_schedule"/>.
+ If any bit in the UpdateRequested field is set, this means that the receiver
+ of the KeyUpdate <bcp14>MUST</bcp14> send its own KeyUpdate message.
+ </t>
+ <figure anchor="figure_keyupdate_msg" title="The Wire Format of the EncryptedMessage header.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24 32
++-----+-----+-----+-----+
+| UpdateRequested |
++-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ </section>
</section>
<section anchor="open" numbered="true" toc="default">
<name>Open Issues</name>
