commit a5befe72ecd2e90797b2c4677d33ef9089dcb4e3
parent a8954e993a56edf08baedb74548896b2b0b3f703
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Tue, 11 Jun 2024 23:28:14 +0200
Updated UDP communicator structure
Diffstat:
1 file changed, 94 insertions(+), 94 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -232,6 +232,11 @@
is sent in one of the first packets. Receivers should keep track (persist) of the monotonic time stamps for each
peer ID to reject possible replay attacks.
</t>
+ <t>
+ All metadata for headers is chosen such that they are indistinguishable from random.
+ There are three distinct message types that are sent and received by UDP communciators: KX, BOX, BROADCAST.
+ In any case, the common header is 32 + 16 bytes in length.
+ </t>
<section anchor="Key_exchange" numbered="true" toc="default">
<name>Key exchange</name>
@@ -239,6 +244,9 @@
Independent of the type of message queue, an X25519-based key exchange is at least initiated once by the sending peer. In cases
where the receiving peer cannot acknowledge the reception of packets, a key exchange is performed for every packet. The UDP
communicator uses a modified version of the standard X25519 key exchange described in section 6.1 of <xref target="RFC7748"/>.
+ The two key pair needed for such a key exchange is an ephemeral key pair generated by the initiating communiciator and the peer
+ identity of the receiving communciator. The ephemeral public key is transfered via a key exchange packet as defines in
+ <xref target="figure_udp_initialkx"/>.
</t>
<t>
While the standard approach securely establishes a secret between both entities, an observer can easily detect a key exchange
@@ -249,84 +257,7 @@
random byte stream. This leaves a censor with the option to either do nothing or intercept all random-looking UDP packets, thereby
disrupting a disproportionate part of today's internet communication.
</t>
- <t>
- 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 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
- points, Enc() Elligator's encoding function, Dec() Elligator's decoding function, REC_ID the receiver's peer identity (a 256-bit EdDSA public key),
- REC_SK the corresponding secret key, EPH_SK a 256-bit ephemeral secret key and SetupCipher() the HKDF defined in <xref target="setup_cipher"/>.
- We can then define the UDP communicator’s key exchange as a KEM:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-Key_Gen() := (REC_SK, REC_ID)
-Encap(REC_ID) := (REPR, (K,IV)) = (Enc(G.EPH_SK, rand), SetupCipher(X25519(EPH_SK, Ed_To_Curve(REC_ID)), 0))
-Decap(REPR) := (K,IV) = SetupCipher(X25519(REC_SK, Dec(REPR)), 0)
- ]]></artwork>
- <t>
- Note that the exchange of the receiver peer identity is not within the scope of the UDP communicator's key exchange and is already assumed to
- be known to the sending peer. It is also important to mention that the ephemeral public key, which is depicted in the KEM as G.EPH_SK, is a point
- on the whole Curve25519 and not restricted to its prime subgroup. This is due to the fact that Elligator's encoding function is defined on the
- whole Curve25519. The exclusive usage of the prime subgroup would restrict the set of potential representatives, which in turn an outside observer
- can trivially recognize.
- </t>
- <t>
- The use of the peer identities for both Ed25519 signatures and X25519-based KEM has been proven to be safe. For further details, refer to the
- paper <xref target="T21"/>.
- </t>
- </section>
- <section anchor="udp_key_schedule" numbered="true" toc="default">
- <name>Key schedule</name>
- <t>
- Once a shared secret MSK is established through the Diffie-Hellman KEM,
- symmetric keys are derived according to a key schedule from a 32-bit
- sequence number seq (in network byte order).
- </t>
- <t>
- The KID derivation uses a hash-based key derivation function (HKDF) as defined in
- <xref target="RFC5869" />, using SHA-512 <xref target="RFC6234"/> for the extraction
- phase and SHA-256 <xref target="RFC6234"/> for the expansion phase.
- PRK_h is key material retrieved using an HKDF using the byte string
- seq as salt and k as initial keying material.
- key and initialization vector are the 256 + 96-bit HKDF expansion result.
- The expansion information input is the string "UDP-IV-KEY":
- </t>
- <artwork anchor="setup_cipher" name="" type="" align="left" alt=""><![CDATA[
-SetupCipher(MSK,SEQ):
- PRK_h := HKDF-Extract (SEQ, MSK)
- K,IV := HKDF-Expand (PRK_h, "UDP-IV-KEY", (256 + 96) / 8)
- return K,IV
- ]]></artwork>
- <t>
- With SetupCipher, a 256-bit AES key as well as a 96-bit IV for use in AES-GCM
- are derived from the MSK and SEQ.
- </t>
- <t>
- Each derived key is uniquely identified using a separately derived
- 256-bit key ID (KID) derived in a similar fashion:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-DeriveKID(MSK,SEQ):
- PRK_h := HKDF-Extract (SEQ, MSK)
- KID := HKDF-Expand (PRK_h, "UDP-KID", 256 / 8)
- return KID
- ]]></artwork>
- <t>
- The sequence number SEQ for any shared secret is initially 0 and incremented
- with each successive encryption (sent/received message).
- </t>
- </section>
- <section anchor="udp_kx" numbered="true" toc="default">
- <name>KX Header</name>
- <t>
- All metadata for headers is chosen such that they are indistinguishable from random.
- There are three distinct message types that are sent and received by UDP communciators: KX, BOX, BROADCAST.
- In any case, the common header is 32 + 16 bytes in length.
- </t>
-<figure anchor="figure_udp_initialkx" title="The binary representation of the initial key exchange packet.">
+ <figure anchor="figure_udp_initialkx" title="The binary representation of the initial key exchange packet.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -365,7 +296,7 @@ DeriveKID(MSK,SEQ):
This data contains a confirmation message (<xref target="figure_udp_confirmation"/>).
</dd>
</dl>
- <t>
+ <t>
In order to prevent replay attacks for KX messages, the plaintext resulting from decryption of the ENCRYPTED DATA
in the KX message starts with a session-specific confirmation header:
</t>
@@ -496,12 +427,81 @@ DeriveKID(MSK,SEQ):
Once a KX message is received and validated, the peer <bcp14>SHOULD</bcp14>
try to acknowledge (ACK) the established shared secret.
</t>
+ <t>
+ 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 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
+ points, Enc() Elligator's encoding function, Dec() Elligator's decoding function, REC_ID the receiver's peer identity (a 256-bit EdDSA public key),
+ REC_SK the corresponding secret key, EPH_SK a 256-bit ephemeral secret key and SetupCipher() the HKDF defined in <xref target="setup_cipher"/>.
+ We can then define the UDP communicator’s key exchange as a KEM:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+Key_Gen() := (REC_SK, REC_ID)
+Encap(REC_ID) := (REPR, (K,IV)) = (Enc(G.EPH_SK, rand), SetupCipher(X25519(EPH_SK, Ed_To_Curve(REC_ID)), 0))
+Decap(REPR) := (K,IV) = SetupCipher(X25519(REC_SK, Dec(REPR)), 0)
+ ]]></artwork>
+ <t>
+ Note that the exchange of the receiver peer identity is not within the scope of the UDP communicator's key exchange and is already assumed to
+ be known to the sending peer. It is also important to mention that the ephemeral public key, which is depicted in the KEM as G.EPH_SK, is a point
+ on the whole Curve25519 and not restricted to its prime subgroup. This is due to the fact that Elligator's encoding function is defined on the
+ whole Curve25519. The exclusive usage of the prime subgroup would restrict the set of potential representatives, which in turn an outside observer
+ can trivially recognize.
+ </t>
+ <t>
+ The use of the peer identities for both Ed25519 signatures and X25519-based KEM has been proven to be safe. For further details, refer to the
+ paper <xref target="T21"/>.
+ </t>
+ </section>
+ <section anchor="udp_key_schedule" numbered="true" toc="default">
+ <name>Key schedule</name>
+ <t>
+ Once a shared secret MSK is established through the Diffie-Hellman KEM,
+ symmetric keys are derived according to a key schedule from a 32-bit
+ sequence number seq (in network byte order).
+ </t>
+ <t>
+ The KID derivation uses a hash-based key derivation function (HKDF) as defined in
+ <xref target="RFC5869" />, using SHA-512 <xref target="RFC6234"/> for the extraction
+ phase and SHA-256 <xref target="RFC6234"/> for the expansion phase.
+ PRK_h is key material retrieved using an HKDF using the byte string
+ seq as salt and k as initial keying material.
+ key and initialization vector are the 256 + 96-bit HKDF expansion result.
+ The expansion information input is the string "UDP-IV-KEY":
+ </t>
+ <artwork anchor="setup_cipher" name="" type="" align="left" alt=""><![CDATA[
+SetupCipher(MSK,SEQ):
+ PRK_h := HKDF-Extract (SEQ, MSK)
+ K,IV := HKDF-Expand (PRK_h, "UDP-IV-KEY", (256 + 96) / 8)
+ return K,IV
+ ]]></artwork>
+ <t>
+ With SetupCipher, a 256-bit AES key as well as a 96-bit IV for use in AES-GCM
+ are derived from the MSK and SEQ.
+ </t>
+ <t>
+ Each derived key is uniquely identified using a separately derived
+ 256-bit key ID (KID) derived in a similar fashion:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+DeriveKID(MSK,SEQ):
+ PRK_h := HKDF-Extract (SEQ, MSK)
+ KID := HKDF-Expand (PRK_h, "UDP-KID", 256 / 8)
+ return KID
+ ]]></artwork>
<t>
- TODO UDPAck payload. TODO UDPRekey payload.
+ The sequence number SEQ for any shared secret is initially 0 and incremented
+ with each successive encryption (sent/received message).
</t>
</section>
- <section anchor="udp_box" numbered="true" toc="default">
- <name>BOX Header</name>
+ <section anchor="udp_message_exchange" numbered="true" toc="default">
+ <name>Message exchange</name>
+ <t>
+ (FIXME: documentation for message exchange is missing, specifically usage of UDP BOX and ACK Header)
+ </t>
<figure anchor="figure_udp_box" title="The binary representation of the UDP Box.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24
@@ -548,12 +548,6 @@ DeriveKID(MSK,SEQ):
the encrypted data can be decrypted.
Otherwise, the message <bcp14>MUST</bcp14> be rejected.
</t>
- <t>
- FIXME: UDPAck, Broadcast
- </t>
- </section>
- <section anchor="udp_ack" numbered="true" toc="default">
- <name>Ack metadata</name>
<figure anchor="figure_udp_ack" title="The wire format of an ACK header.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 16
@@ -582,8 +576,11 @@ DeriveKID(MSK,SEQ):
]]></artwork>
</figure>
</section>
- <section anchor="udp_rekey" numbered="true" toc="default">
- <name>Rekey metadata</name>
+ <section anchor="tcp_rekeying" numbered="true" toc="default">
+ <name>Rekeying</name>
+ <t>
+ (FIXME: rekeying procedure documentation is missing)
+ </t>
<figure anchor="figure_udp_rekey" title="The wire format of a REKEY header.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 16
@@ -603,7 +600,10 @@ DeriveKID(MSK,SEQ):
</figure>
</section>
<section anchor="udp_bc" numbered="true" toc="default">
- <name>BROADCAST Message</name>
+ <name>Broadcast</name>
+ <t>
+ (FIXME: Broadcast documentation is missing)
+ </t>
</section>
</section>
<section anchor="tcp_comm" numbered="true" toc="default">
@@ -981,7 +981,7 @@ SetupCipher(MSK):
and X25519-based KEM is proven to be secure. For more comprehensive information, please refer to the paper [T21].
</t>
</section>
- <section anchor="message_exchange" numbered="true" toc="default">
+ <section anchor="tcp_message_exchange" numbered="true" toc="default">
<name>Message exchange</name>
<t>
Once the handshake is completed actual payloads can be exchanged bi-directionally using TCP Box messages. A TCP Box message
@@ -1035,8 +1035,8 @@ SetupCipher(MSK):
</dl>
</section>
- <section anchor="rekeying_process" numbered="true" toc="default">
- <name>Rekeying process</name>
+ <section anchor="udp_rekeying" numbered="true" toc="default">
+ <name>Rekeying</name>
<t>
(FIXME: documentation missing)
</t>
