commit 887899997635009b3fbc0a8ad7bdf887561b1a6a
parent 360cede2f64bfe98f9587795211605fb02d859dd
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Mon, 27 May 2024 12:30:20 +0200
Rephrased UDP Communicator Key Exchange
Diffstat:
1 file changed, 62 insertions(+), 60 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -203,83 +203,85 @@
<section anchor="udp_comm" numbered="true" toc="default">
<name>UDP communicator</name>
<t>
- The UDP communicator implements an encryption layer that protects both the payload and the communicator's
- specific metadata (not to be confused with the UDP header). In particular, any packet sent by the communicator
- is indistinguishable from random noise to an outside observer.
- </t>
- <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 initiator of the connection creates an ephemeral
- key pair to encrypt the message for the target peer identity. The encrypted message is prepended by a
- KX Header, which contains the ephemeral public key and is then sent to the target peer. This procedure
- is repeated with a new ephemeral key for each subsequent packet. The wire format for such a KX packet can
- be found in <xref target="figure_udp_initialkx"/>.
- While the communicator always offers this type of message queue to a reachable peer, it is inefficient for
- high-volume data transfer because a new key exchange is conducted for every packet.
- </t>
- <t>
- If the target peer acknowledges the reception of a KX packet, the resulting key can be reused. Such an ACK
- packet can be sent either via a bi-directional UDP connection or a backchannel connection provided by
- TRANSPORT. The wire format for an ACK packet is depicted in <xref target="figure_udp_ack"/>.
- 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
- will prioritize it if available.
- </t>
- <t>
- The initiating communicator attempts to authenticate its peer ID (public key) in the initial packets by signing
- a monotonic time stamp, its peer ID, and the target peerID. This signed data, along with the signature, 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>
+ The UDP communicator implements an encryption layer that protects both the payload and the communicator's
+ specific metadata (not to be confused with the UDP header). In particular, any packet sent by the communicator
+ is indistinguishable from random noise to an outside observer.
+ </t>
+ <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. The encrypted message is prepended by a
+ KX Header, which contains the ephemeral public key and is then sent to the target peer. This procedure
+ is repeated with a new ephemeral key for each subsequent packet. The wire format for such a KX packet can
+ be found in <xref target="figure_udp_initialkx"/>.
+ While the communicator always offers this type of message queue to a reachable peer, it is inefficient for
+ high-volume data transfer because a new key exchange is conducted for every packet.
+ </t>
+ <t>
+ If the target peer acknowledges the reception of a KX packet, the resulting key can be reused. Such an ACK
+ packet can be sent either via a bi-directional UDP connection or a backchannel connection provided by
+ TRANSPORT. The wire format for an ACK packet is depicted in <xref target="figure_udp_ack"/>.
+ 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
+ will prioritize it if available.
+ </t>
+ <t>
+ The communicator initiating the connection attempts to authenticate its peer ID (public key) in the initial packets
+ by signing a monotonic time stamp, its peer ID, and the target peer ID. This signed data, along with the signature,
+ 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>
<section anchor="Key_exchange" numbered="true" toc="default">
<name>Key exchange</name>
<t>
- In order to establish a shared secret, an X25519-based key exchange is initiated by the sending peer. The sender generates an
- ephemeral key pair first and uses the ephemeral private key and the receiver's peer identity to calculate the shared secret.
- To hide the fact that a key exchange is being performed, the sender peer projects the ephemeral public key into a random-looking
- byte stream (later referenced as the representative) before sending it to the receiver peer. The receiver peer can then recover
- the ephemeral public key of the sender peer and calculate the same shared secret with its own private key.
- (TODO) Motivation for hiding key exchange
+ 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"/>.
+ </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. Without additional measures,
+ an observer can recognize this transmission and deduce that an ECC-based key exchange is occurring. In a censored environment,
+ this could lead to packet interception, preventing communication between peers. The UDP communicator addresses this by encoding
+ 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 (KX) packet also appear random, the entire packet is indistinguishable from a
+ random byte stream.
</t>
<t>
- The projection of the ephemeral public key is necessary if one wants to hide the fact that an ECC-based key exchange is being performed.
- This is due to the structure of ECC public keys, which are not equally distributed with respect to the underlying group of the curve and
- therefore distinguishable from random. The UDP communicator uses Elligator's encoding and decoding functions for the projection
- and recovery of the ephemeral public key. More details about the construction of the representative and Elligator can be found in
- <xref target="Elligator"/>
+ Upon receiving a KX packet, the receiving peer decodes the representative into the original ephemeral public key and subsequently
+ calculates the shared secret. The UDP communicator utilizes Elligator for the encoding and decoding of the ephemeral
+ public key. More details about the construction of the representative and Elligator can be found in <xref target="Elligator"/>.
</t>
<t>
- Let G be the basepoint of Curve25519, Ed25519_To_Curve25519() a function which converts Ed25519 points to their corresponding Curve25519
- points, Enc() Elligator's encoding function, Dec() Elligator's decoding function, RECEIVER_PEER_ID a 256-bit EdDSA public key,
- RECEIVER_SK the corresponding secret key and EPH_SK a 256-bit ephemeral secret key.
- We can than define the described key exchange as a KEM:
+ Let G be the basepoint of Curve25519, Ed25519_To_Curve25519() a function which converts Ed25519 points to their corresponding Curve25519
+ points, Enc() Elligator's encoding function, Dec() Elligator's decoding function, RECEIVER_PEER_ID a 256-bit EdDSA public key,
+ RECEIVER_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() := (RECEIVER_SK, RECEIVER_PEER_ID)
-Encap() := (R, MSK) = (Enc(G.EPH_SK, rand), X25519(EPH_SK, Ed25519_To_Curve25519(RECEIVER_PEER_ID)))
-Decap(R) := (MSK) = X25519(RECEIVER_SK, Dec(R))
+Encap() := (R, (K,IV)) = (Enc(G.EPH_SK, rand), SetupCipher(X25519(EPH_SK, Ed25519_To_Curve25519(RECEIVER_PEER_ID)), 0))
+Decap(R) := (K,IV) = SetupCipher(X25519(RECEIVER_SK, Dec(R)), 0)
]]></artwork>
<t>
- (TODO) KDF is mising
- Note that the exchange of the receiver peer identity is not within the scope of UDP Communicator's key exchange and is already assumed to
- be known to the sender 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.
- (TODO) Explaination why KEM secure
+ 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 sender 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>
+ (TODO) Explaination why KEM secure even if identities are used for signature
</t>
</section>
<section anchor="Elligator" numbered="true" toc="default">
<name>Elligator</name>
<t>
- The UDP Communicator will always perform atleast one Diffie-Hellman key exchange with the target peer independent on the type of message
- queue. The key exchange requires the transmission of an ephemeral public key from the sender peer to the target peer. If no additional
- measures are taken, an outside observer can recognize the transmission of that ephemeral key and deduce that an ECC-based key exchange
- is being performed.
- </t>
- <t>
+ This is due to the structure of ECC public keys, which are not equally distributed with respect to the underlying group of the curve and
+ therefore distinguishable from random.
+
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 + AX^2 + X mod Q, whereas A and Q are parameters for Curve25519 specified in <xref target="RFC7748"/>. For any valid x-coordinate the left
side of the equation is therefore always a quadratic number. An attacker could thus read the x-coordinate from the KX Header and check if
@@ -340,7 +342,7 @@ Dec(R):
key and initialization vector are the 256 + 96-bit HKDF expansion result.
The expansion information input is the string "UDP-IV-KEY":
</t>
- <artwork name="" type="" align="left" alt=""><