[lsd0007] 01/02: Updated TCP Communicator introduction

[gnunet]

This is an automated email from the git hooks/post-receive script.

pedram pushed a commit to branch master
in repository lsd0007.

commit 271c7dc0dac845c139e891fde5075f84951b2fa0
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
AuthorDate: Sun Jun 9 17:08:49 2024 +0200

    Updated TCP Communicator introduction
---
 draft-gnunet-communicators.xml | 72 ++++++++++++++++++++++--------------------
 1 file changed, 37 insertions(+), 35 deletions(-)

diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
index 1ad18e5..3bcf72a 100644
--- 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>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.