[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0007] branch master updated: Updated TCP communicator rekeying
|
From: |
gnunet |
|
Subject: |
[lsd0007] branch master updated: Updated TCP communicator rekeying |
|
Date: |
Thu, 13 Jun 2024 17:04:19 +0200 |
This is an automated email from the git hooks/post-receive script.
pedram pushed a commit to branch master
in repository lsd0007.
The following commit(s) were added to refs/heads/master by this push:
new 0b25a60 Updated TCP communicator rekeying
0b25a60 is described below
commit 0b25a60489d090e4abbcc7d0ba6370fca3121490
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
AuthorDate: Thu Jun 13 17:03:32 2024 +0200
Updated TCP communicator rekeying
---
draft-gnunet-communicators.xml | 165 +++++++++++++++++++++++++++++++++++++++--
1 file changed, 157 insertions(+), 8 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
index 1f047e1..d5c17a3 100644
--- a/draft-gnunet-communicators.xml
+++ b/draft-gnunet-communicators.xml
@@ -576,7 +576,7 @@ DeriveKID(MSK,SEQ):
]]></artwork>
</figure>
</section>
- <section anchor="tcp_rekeying" numbered="true" toc="default">
+ <section anchor="udp_rekeying" numbered="true" toc="default">
<name>Rekeying</name>
<t>
(FIXME: rekeying procedure documentation is missing)
@@ -931,7 +931,12 @@ 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 the use of AES-CTR and HMAC-SHA512. The TCP communicator doesn't
follow the standard X25519-KEM as described in
+ for the use of AES-CTR and HMAC-SHA512. Later, further key exchanges are
performed during each rekeying process. More
+ about the initial handshake and rekeying can be found in <xref
target="tcp_handshake"/> and
+ <xref target="tcp_rekeying"/> respectively.
+ </t>
+ <t>
+ The TCPcommunicator 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
@@ -993,11 +998,12 @@ SetupCipher(MSK):
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 <bcp14>MUST</bcp14> use
a padding free encryption scheme such as AES-CTR for encryption.
Additionally, we restrict the attacker's ability for replay
- attacks by exchanging new key material after a fix amount of transferred
data (FIXME: currently 4GB, refer to rekeying process).
- The necessary key exchanges to establish the new key material are
protected using monotonic timestamps.
+ attacks by exchanging new key material after a randomly chosen amount of
transferred data as described in
+ <xref target="tcp_rekeying"/>. The necessary key exchanges to establish
the new key material are protected using monotonic
+ timestamps.
</t>
<t>
- (FIXME: hmac, MtE discussion, padding-oracle, rekeying).
+ (FIXME: hmac, MtE discussion, padding-oracle).
</t>
<figure anchor="figure_tcp_box" title="The binary representation of the
tcp box packet.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1026,7 +1032,7 @@ SetupCipher(MSK):
<dt>TYPE</dt>
<dd>
A 16-bit signature type flag in network byte order. The value of
this
- field <bcp14>MUST</bcp14> be XXXX (FIXME: Value missing).
+ field <bcp14>MUST</bcp14> be 1451.
</dd>
<dt>HASHCODE</dt>
<dd>
@@ -1035,11 +1041,154 @@ SetupCipher(MSK):
</dl>
</section>
- <section anchor="udp_rekeying" numbered="true" toc="default">
+ <section anchor="tcp_rekeying" numbered="true" toc="default">
<name>Rekeying</name>
<t>
- (FIXME: documentation missing)
+ After each key exchange, up to 400 MB of data is transferred until
rekeying is triggered by the sender of the communication direction.
+ The actual amount of transferred data <bcp14>SHOULD</bcp14> be chosen
randomly. If the chosen byte quantity is not reached after
+ one day, rekeying is set off anyway.
+ </t>
+ <t>
+ The receiving communicator is signaled about a rekeying through the
dispatch of a TCP Rekey packet as defined in
+ <xref target="figure_tcp_rekey"/>. The packet <bcp14>MUST</bcp14> be
encrypted with the current key. Due to the encryption of the packet,
+ the encoding of the new ephemeral public key with Elligator is not
needed. Similarly to the initial handshake, the ephemeral public key
+ is used to perform a key exchange from which new key material for the
encryption and authentication code scheme are derived. For further
+ details please refer to <xref target="tcp_KEM"/>. Note that rekeying
process is not acknowledged by the receiver, so the sender might send
+ new payload encrypted by the new key right after sending the TCP Rekey
packet.
</t>
+ <figure anchor="figure_tcp_rekey" title="The binary representation of the
TCP Rekey packet.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | TYPE (0x0X) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| HASHCODE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EPHEMERAL PUBLIC KEY |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| MONOTONIC TIMESTAMP |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ <dl>
+ <dt>SIZE</dt>
+ <dd>
+ A 16-bit value containing the length of the message in bytes
+ in network byte order.
+ </dd>
+ <dt>TYPE</dt>
+ <dd>
+ A 16-bit signature type flag in network byte order. The value of
this
+ field <bcp14>MUST</bcp14> be 1450.
+ </dd>
+ <dt>HASHCODE</dt>
+ <dd>
+ A 256-bit HMAC-SHA512 hashcode of this TCP Rekey packet. The
hashcode is
+ computed with the hashcode field initially set to zero and is
inserted afterward.
+ </dd>
+ <dt>EPHEMERAL PUBLIC KEY</dt>
+ <dd>
+ A 256-bit Curve25519 public key which is used as part of an
X25519-based
+ key exchange to establish a shared secret.
+ </dd>
+ <dt>Signature</dt>
+ <dd>
+ A 512-bit EdDSA signature. The signature is calculated over
+ the data as defined in <xref target="figure_tcp_rekey_sig"/>.
+ </dd>
+ <dt>MONOTONIC TIMESTAMP</dt>
+ <dd>
+ FIXME.
+ </dd>
+ </dl>
+ <figure anchor="figure_tcp_rekey_sig" title="The wire format used for
creating the signature of the TCP Rekey packet.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | PURPOSE (0x0X) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SENDER PEER ID |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| RECEIVER PEER ID |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EPHEMERAL PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| MONOTONIC TIMESTAMP |
+| |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ </figure>
+ <dl>
+ <dt>SIZE</dt>
+ <dd>
+ A 32-bit value containing the length of the signed data in bytes
+ in network byte order.
+ </dd>
+ <dt>PURPOSE</dt>
+ <dd>
+ A 32-bit signature purpose flag in network byte order. The value of
this
+ field <bcp14>MUST</bcp14> be 32. It defines the context in which
+ the signature is created so that it cannot be reused in other parts
+ of the protocol including possible future extensions.
+ The value of this field corresponds to an entry in the
+ GANA "GNUnet Signature Purpose" registry <xref target="gana"/>.
+ </dd>
+ <dt>SENDER PEER ID</dt>
+ <dd>
+ A 256-bit EdDSA public key.
+ </dd>
+ <dt>RECEIVER PEER ID</dt>
+ <dd>
+ A 256-bit EdDSA public key.
+ </dd>
+ <dt>EPHEMERAL PEER ID</dt>
+ <dd>
+ A 256-bit EdDSA public key.
+ </dd>
+ <dt>MONOTONIC TIMESTAMP</dt>
+ <dd>
+ FIXME.
+ </dd>
+ </dl>
</section>
</section>
<section anchor="quic_comm" numbered="true" toc="default">
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0007] branch master updated: Updated TCP communicator rekeying,
gnunet <=