commit 4d07e5cb78be0a9874f46326620f490da26399ae
parent d3be28a5b8d0b6eda50239ca1a7c941fe5e739aa
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Mon, 10 Jun 2024 15:04:43 +0200
Adjusted different parts of TCP communicator
Diffstat:
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -253,7 +253,7 @@
Upon receiving a KX packet, the receiving peer decodes the representative into the original ephemeral public key and subsequently
computes the shared secret. The UDP communicator utilizes Elligator for the encoding and decoding of the ephemeral public key
described in Section 5. <xref target="BHKL13"/>. More details about the construction of the representative and Elligator's
- usage within the UDP communicator can be found in <xref target="Elligator"/>.
+ usage can be found in <xref target="Elligator"/>.
</t>
<t>
Let G be the basepoint of Curve25519, Ed_To_Curve() a function which converts Ed25519 points to their corresponding Curve25519
@@ -634,7 +634,7 @@ DeriveKID(MSK,SEQ):
using the Elligator encoding function.
In contrast to the plain public key, the encoded public key (also called the representative) is indistinguishable
from a random-looking byte stream, which protects against censors targeting messages containing cryptographic
- material. More information about Elligator and its usage can be found in <xref target="Elligator"/>.
+ material.
</t>
<t>
The sent public key <bcp14>MUST</bcp14> be directly followed by an encrypted TCP handshake packet as shown
@@ -931,7 +931,15 @@ DeriveKID(MSK,SEQ):
<name>Key exchange</name>
<t>
During the initial handshake, each communication channel performs an X25519-based KEM, which provides the key material
- for encrypting packets via AES-CTR and computing MACs via HMAC.
+ for the use of AES-CTR and HMAC-SHA512. The TCP communicator doesn't follow the standard X25519-KEM as described in
+ section 6.1 of <xref target="RFC7748"/> because Curve25519 public keys are recognisable by an outside observer. In a
+ censored environment, this could lead to the interception of such messages and ultimately prevent communication
+ between peers. We circumvent this issue by encoding public keys using Elligator, a mathematical method to encode curve points
+ into random-looking byte streams (referred to as the "representative").
+ Since all data, apart from the public keys, is only sent encrypted, all the data send over the communication channel
+ is indistinguishable from a random byte stream. This forces a censor to choose between taking no action or intercepting all
+ random-looking TCP packets, thereby significantly disrupting a large portion of modern internet communication.
+ For more information about elligator and its usage, please refer to <xref target="Elligator"/>.
</t>
<t>
Let G be the basepoint of Curve25519, Ed_To_Curve() a function which converts Ed25519 points to their corresponding
@@ -982,8 +990,9 @@ SetupCipher(MSK):
</t>
<t>
TCP Box messages follow the mac-then-encrypt approach to hide the size of the payload and achieve a zero-plaintext design.
- The receiving peer needs to decrypt both the TCP Box packet and the payload first before initiating the verification of the
- hmac.
+ The HMAC utilizes SHA512 as the underlying hash function and is ratcheted after each operation. Given the mac-then-encrypt
+ approach, additional safeguards are needed to protect against oracle padding attacks. Therefore, we use AES-CTR for encryption,
+ as it doesn't require padding.
</t>
<t>
(FIXME: hmac, MtE discussion, padding-oracle, rekeying).
@@ -1019,7 +1028,7 @@ SetupCipher(MSK):
</dd>
<dt>HASHCODE</dt>
<dd>
- A 256-bit computed hmac for the subsequently sent payload.
+ A 256-bit HMAC-SHA512 hashcode for the subsequently sent payload.
</dd>
</dl>
</section>
