commit 271c7dc0dac845c139e891fde5075f84951b2fa0
parent ee37fecf58232e8d949b40172f353034b4dad8be
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Sun, 9 Jun 2024 17:08:49 +0200
Updated TCP Communicator introduction
Diffstat:
1 file changed, 37 insertions(+), 35 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -655,45 +655,23 @@ DeriveKID(MSK,SEQ):
</section>
</section>
<section anchor="tcp_comm" numbered="true" toc="default">
- <name>TCP communicators</name>
+ <name>TCP communicator</name>
<t>
- TCP communicators communicate over and encrypted, bi-directional communication channel.
- Each direction of the communication is encryption using a dedicated shared secret
- which is exchanged in initial key exchange handshakes.
- Once shared secrets are established, regular re-keying occurs after a certain amount of bytes
- transmitted (FIXME: Currently, hard-coded to 4 GB!).
+ TCP communicators always establish an encrypted and bi-directional communication channel. For
+ each direction of communication, a dedicated shared secret is used to both encrypt and
+ authenticate messages. These shared secrets are exchanged during the initial handshake. After a
+ certain amount of data has been transmitted, re-keying occurs to renew the key material
+ (FIXME: Currently, hard-coded to 4 GB!). Note that the re-keying process is triggered individually
+ for each communication direction.
</t>
<t>
- Messages are encrypted using the encrypt-then-mac paradigm. Yes, we <bcp14>MUST</bcp14>
- use mac-then-encrypt as we want to hide the message size on the wire to achieve a
- zero-plaintext design.
- As encryption is done using AES-CTR, padding oracle attacks do not apply (WHY?).
- Also, due to the use of ephemeral keys in combination with monotonic time stamps any
- attacker is limited in using the oracle as replay attacks are prevented.
+ To achieve a zero-plaintext design, we <bcp14>MUST</bcp14> use the mac-then-encrypt approach to
+ hide the message size on the wire. Extra caution needs to be taken due to the vulnerability of
+ the mac-then-encrypt design to padding oracle attacks. To mitigate this issue, the TCP communicator
+ uses AES-CTR for encryption, which does not require padding. Additionally, the use of ephemeral keys
+ combined with monotonic timestamps limits an attacker's ability to exploit the oracle, as replay
+ attacks are prevented.
</t>
- <t>
- The first data from a communicator that is trying to establish a connection
- is always an ephemeral public key.
- This key is used to derive an initial symmetric key which is used to decrypt
- the following data.
- Let MSK be the symmetric key decapsulated from the ephemeral public key with
- the receiving peer's private key.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-SetupCipher(MSK):
- PRK_k := HKDF-Extract ("TCP-key", MSK)
- K := HKDF-Expand (PRK_k, PEERID, 256 / 8)
- PRK_i := HKDF-Extract ("TCP-ctr", MSK)
- IV := HKDF-Expand (PRK_i, PEERID, 128 / 8)
- PRK_mac := HKDF-Extract ("TCP-hmac", MSK)
- K_mac := HKDF-Expand (PRK_i, PEERID, 512 / 8)
- return K,IV,K_mac
- ]]></artwork>
- <t>
- The above K and IV are used to decrypt the following 136 bytes of data
- which are expected to consist of a TCP handshake message as defined in
- <xref target="tcp_handshake"/> below.
- </t>
<section anchor="tcp_handshake" numbered="true" toc="default">
<name>Handshake</name>
<figure anchor="figure_tcp_handshake" title="The wire format of a TCP handshake.">
@@ -889,6 +867,30 @@ SetupCipher(MSK):
bi-directionally using TCP Box messages. FIXME hmac, MtE discussion, padding-oracle, etc
</t>
</section>
+ <section anchor="tcp_key_schedule" numbered="true" toc="default">
+ <name>Key schedule</name>
+ <t>
+ This key is used to derive an initial symmetric key which is used to decrypt
+ the following data.
+ Let MSK be the symmetric key decapsulated from the ephemeral public key with
+ the receiving peer's private key.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+SetupCipher(MSK):
+ PRK_k := HKDF-Extract ("TCP-key", MSK)
+ K := HKDF-Expand (PRK_k, PEERID, 256 / 8)
+ PRK_i := HKDF-Extract ("TCP-ctr", MSK)
+ IV := HKDF-Expand (PRK_i, PEERID, 128 / 8)
+ PRK_mac := HKDF-Extract ("TCP-hmac", MSK)
+ K_mac := HKDF-Expand (PRK_i, PEERID, 512 / 8)
+ return K,IV,K_mac
+ ]]></artwork>
+ <t>
+ The above K and IV are used to decrypt the following 136 bytes of data
+ which are expected to consist of a TCP handshake message as defined in
+ <xref target="tcp_handshake"/> below.
+ </t>
+ </section>
</section>
<section anchor="quic_comm" numbered="true" toc="default">
<name>QUIC communicator</name>
