commit bce32abca61fba2c52407946ce5dc1321078c4da
parent 1d229c465213d531ef4cb06482c77b960dccdd56
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Mon, 17 Jun 2024 17:37:23 +0200
Updated UDP communicator
Diffstat:
1 file changed, 63 insertions(+), 57 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -210,9 +210,9 @@
<t>
For any new connection to a target peer, the communicator attempts to establish a shared secret using an
Elliptic-Curve Diffie-Hellman key exchange. The communicator initiating the connection creates an ephemeral
- key pair to encrypt the message for the target peer identity. Both the ephemeral public key and the encrypted
- message are sent to the receiving peer together with an authentication tag that authenticates the encrypted
- message. Independent of the payload, each message includes the sender's peer ID, a monotonic timestamp, and a
+ key pair to encrypt the data for the target peer identity. Both the ephemeral public key and the encrypted
+ data are sent to the receiving peer together with an authentication tag that authenticates the encrypted
+ data. Independent of the payload, each message includes the sender's peer identity, a monotonic timestamp, and a
signature over the session's meta data. Receivers should keep track of the monotonic timestamps for each peer
ID to reject possible replay attacks. For each subsequent message the same procedure is conducted with a new
ephemeral key pair.
@@ -220,16 +220,17 @@
high-volume data transfer because a new key exchange is conducted for every message.
</t>
<t>
- If the target peer acknowledges the reception of a message, the employed key can be reused. Such acknowledgemnts
+ If the target peer acknowledges the reception of a message, the employed key can be reused. Such acknowledgments
can be sent either via a bi-directional UDP connection or a backchannel connection provided by TRANSPORT.
This acknowledgment prompts the communicator to offer a new queue to TRANSPORT, which has a higher priority
than the default queue but starts with limited capacity. The capacity increases whenever the communicator
- receives an ACK for a transmission. This queue is suitable for high-volume data transfer, and TRANSPORT
+ receives an acknowledgment for a transmission. This queue is suitable for high-volume data transfer, and TRANSPORT
will prioritize it if available.
</t>
<t>
There are three distinct message types that are sent and received by UDP communicators: KX, BOX and BROADCAST.
- For KX and BOX messages, their metadata is chosen such that they are indistinguishable from random.
+ For KX and BOX messages, their metadata is chosen such that they are indistinguishable from random. (FIXME:
+ not the case for BROADCAST).
</t>
<section anchor="Key_exchange" numbered="true" toc="default">
@@ -239,19 +240,19 @@
where the receiving peer cannot acknowledge the reception of messages, a key exchange is performed for every message. 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 message as defined in
+ identity of the receiving communciator. The ephemeral public key is transfered via a key exchange (KX) message as defined 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
due to the transmission of an ephemeral public key from the sending peer to the receiving peer. In a censored environment,
- this could lead to packet interception, preventing communication between peers. The UDP communicator addresses this by encoding
+ this could lead to packet interception, preventing communication between peers. The UDP communicator <bcp14>MUST</bcp14> encode
the ephemeral public key into a random-looking byte stream (referred to as the "representative") before sending it. Since the
GCM tag and the encrypted data in the key exchange message also appear random, the entire message is indistinguishable from a
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>
- <figure anchor="figure_udp_initialkx" title="The binary representation of the key exchange message.">
+ <figure anchor="figure_udp_initialkx" title="The binary representation of the KX message.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -281,20 +282,21 @@
</dd>
<dt>GCM TAG</dt>
<dd>
- A 128-bit GCM tag used to authenticate the ciphertext immediately following this KX.
+ A 128-bit GCM tag used to authenticate the ciphertext immediately following the header part of the KX message.
</dd>
<dt>ENCRYPTED DATA</dt>
<dd>
The remaining data (as indicated by SIZE) is AES-GCM encrypted using the current session key and authenticated
through the GCM TAG.
- This data contains a confirmation message (<xref target="figure_udp_confirmation"/>).
</dd>
</dl>
<t>
In order to prevent replay attacks for KX messages, the plaintext resulting from decryption of the encrypted data
- starts with a session-specific confirmation header:
+ <bcp14>MUST</bcp14> must start with a session-specific Confirmation header as defined in <xref target="figure_udp_confirmation"/>.
+ It includes the sender's peer identity and a monotonic timestamp which the receiving peer <bcp14>MUST</bcp14> keep track
+ for each peer identity to reject possible replay attacks.
</t>
-<figure anchor="figure_udp_confirmation" title="The binary representation of the KX confirmation header">
+<figure anchor="figure_udp_confirmation" title="The binary representation of the KX Confirmation header">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -344,7 +346,12 @@
The message payload data.
</dd>
</dl>
- <figure anchor="figure_udp_handshake_sig" title="The wire format used for creating the signature of the UDP Confirmation header.">
+ <t>
+ The Confirmation header also includes a signature over the session's meta data, which is signed with the corresponding private key of
+ the sender peer identity. The data format over which the signature is computed is defined in <xref target="figure_udp_handshake_sig"/>
+ </t>
+ <figure anchor="figure_udp_handshake_sig" title="The wire format of the data structure over which the signature of the UDP Confirmation
+ header is computed.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -374,11 +381,6 @@
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
-| NONCE |
-| |
-| |
-| |
-+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<dl>
@@ -390,7 +392,7 @@
<dt>PURPOSE</dt>
<dd>
A 32-bit signature purpose flag in network byte order. The value of this
- field <bcp14>MUST</bcp14> be 33. It defines the context in which
+ field <bcp14>MUST</bcp14> be 33. 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
@@ -406,63 +408,66 @@
</dd>
<dt>EPHEMERAL PUBLIC KEY</dt>
<dd>
- A 256-bit Curve25519 public key. This public key is send in an Elligator encodeded format, called
+ A 256-bit Curve25519 public key. This public key is send in an Elligator encoded format, called
the representative, in the KX header.
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
FIXME.
</dd>
- <dt>NONCE</dt>
- <dd>
- A 256-bit random value.
- </dd>
</dl>
<t>
Upon receiving a KX message, 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
+ described in section 5 of <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:
+ We can then define the UDP communicator’s key exchange for the first message 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)
+Encap(REC_ID) := (REPR, (K,IV)) = (REPR, SetupCipher(MSK, 0)) = (Enc(G.EPH_SK, rand), SetupCipher(X25519(EPH_SK, Ed_To_Curve(REC_ID)), 0))
+Decap(REPR) := (K,IV) = SetupCipher(MSK, 0) = 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. We also want emphasize, that 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"/>.
+ Both the sending and the receiving peer <bcp14>SHOULD</bcp14> store the master shared secret MSK and attribute it to the corresponding peer.
+ In case of an acknowledgment from the receiving peer, the established MSK can be reused by iterativly increasing the sequence number SEQ for
+ SetupCipher(MSK, SEQ).
+ </t>
+ <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. One way to exchange peer identites is through the means of UDP BROADCAST messages as described
+ in <xref target="udp_bc"/>. 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>
+ Additional data might be inserted after the Confirmation header as part of the encrypted data of the KX message. Padding may be necessary
+ due to the use of AES-GCM. Once a KX message is received and validated, the peer <bcp14>SHOULD</bcp14> try to acknowledge the established
+ shared secret to switch to the more efficient queue. The details about the acknowledgment process and subsequent message exchange can be
+ found in <xref target="udp_message_exchange"/>.
</t>
<t>
- Additional data might be inserted after the Confirmation header as part of the encrypted data of the KX message. Padding may be necessary due to the
- use of AES-GCM. Once a KX message is received and validated, the peer <bcp14>SHOULD</bcp14> try to acknowledge the established shared secret to switch
- to the more efficient queue. The details about the acknowledgment process and subsequent message exchange can be found in <xref target="udp_message_exchange"/>.
+ We want emphasize, that the use of the peer identities for both Ed25519 signatures and the 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 within the Diffie-Hellman KEM, symmetric keys are derived according to a key schedule from a 32-bit
- sequence number seq (in network byte order).
+ Once a shared secret MSK is established through within 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":
+ 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 a salt and k as initial keying material. The key K and
+ initialization vector IV 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):
@@ -497,10 +502,10 @@ DeriveKID(MSK,SEQ):
offers a faster way of communication with the reuse of a shared secret. For this purpose, the receiver of a message <bcp14>SHOULD</bcp14>
acknowledge the reception to signal the sender that the same shared secret can be reused. The sender can then use the acknowledged shared
secret and increment the utilized sequence number for each subsequent message to derive new symmetric key material. These messages are
- send as BOX messages, which incorporate a KID as defined in <xref target="derive_kid"/> to identify both the shared secret and sequence
- number. The wire format of a BOX message is depicted in <xref target="figure_udp_box"/>.
+ send as BOX messages, which incorporate a KID as defined in <xref target="derive_kid"/> to identify both the master shared secret and
+ sequence number. The wire format of a BOX message is depicted in <xref target="figure_udp_box"/>.
</t>
- <figure anchor="figure_udp_box" title="The binary representation of the UDP Box.">
+ <figure anchor="figure_udp_box" title="The binary representation of the UDP Box message.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -541,7 +546,7 @@ DeriveKID(MSK,SEQ):
<t>
An acknowldgement can be sent in various ways is ultimately decided by TRANSPORT. If the target peer can also reach the sending peer via
UDP messages, both KX messages or BOX messages could be utilized to send the acknowledgment as their payload. TRANSPORT could also choose
- to utilize another communicator type to send the acknowledgment (backchannel). Either way, acknowledgments are always sent in form of a
+ to utilize another communicator type to send the acknowledgment (backchannel). Either way, acknowledgments are always sent in form of an
ACK header. The wire format of the ACK header can be seen in <xref target="figure_udp_ack"/>.
</t>
<figure anchor="figure_udp_ack" title="The wire format of an ACK header.">
@@ -574,7 +579,7 @@ DeriveKID(MSK,SEQ):
<dl>
<dt>SIZE</dt>
<dd>
- A 32-bit value containing the length of the signed data in bytes in network byte order.
+ A 16-bit value containing the length of the message in bytes in network byte order.
</dd>
<dt>TYPE</dt>
<dd>
@@ -591,9 +596,10 @@ DeriveKID(MSK,SEQ):
</dl>
<t>
To avoid having to acknowledge every single message individually, the sender of an acknowledgment can specify the allowed sequence number for
- the sender in the ACK header. Notice how a receiver should have precalculated all derived keys and corresponding KIDs for which it has already
- sent ACKs. Consequently, for valid sequence numbers below the current ACK limit, KID should match one of the precalculated keys in the key cache,
- and the encrypted data can be decrypted. Otherwise, the message <bcp14>MUST</bcp14> be rejected.
+ the sender in the ACK header.
+ The receiver <bcp14>MUST</bcp14> precalculate all derived keys and corresponding KIDs for which it has already sent ACKs. Consequently, for
+ valid sequence numbers below the current ACK limit, KID should match one of the precalculated keys in the key cache, and the encrypted data
+ can be decrypted. Otherwise, the message <bcp14>MUST</bcp14> be rejected.
</t>
<t>
Multiple shared secrets can be used simultaneously between the sending peer and target peer (FIXME: currently limited to 256). Should the
@@ -630,7 +636,7 @@ DeriveKID(MSK,SEQ):
<dl>
<dt>SIZE</dt>
<dd>
- A 16-bit value containing the length of the message in bytes in network byte order
+ A 16-bit value containing the length of the message in bytes in network byte order.
</dd>
<dt>TYPE</dt>
<dd>
@@ -1322,7 +1328,7 @@ SetupCipher(MSK):
<name>Elligator</name>
<t>
In case of Montgomery curves, such as Curve25519, a point [X, Y] on that curve (e.g. the ephemeral public key) follows the equation
- Y^2 = X^3 + A * X^2 + X mod P, where A and P are parameters for Curve25519 specified in Section 4.1 of <xref target="RFC7748"/>. For any
+ Y^2 = X^3 + A * X^2 + X mod P, where A and P are parameters for Curve25519 specified in section 4.1 of <xref target="RFC7748"/>. For any
valid x-coordinate, the left side of the equation is always a quadratic number. An attacker could read the x-coordinate
and verify if this property holds. While this property holds for any valid Curve25519 point, it only holds in about 50% of the cases for a
random number. By observing multiple KX packets, an attacker can be certain that curve points are being sent if the property consistently holds.
