commit 95da98bf28e4c1a35ab3c873333291e5551bb4cc
parent 37313deba2984c313bd2207211702384e32fa51a
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Sat, 25 May 2024 18:22:47 +0200
Rephrased UDP Communicator
Diffstat:
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -203,20 +203,19 @@
<section anchor="udp_comm" numbered="true" toc="default">
<name>UDP communicator</name>
<t>
- The UDP communicator implements an encryption layer which both protects
- the payload to be sent and the communicator's specific metadata (not to be confused with the UDP-Header).
- In particular any packet send by the communicator is indistinguishable from a random noise for an outside observer.
+ 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 tries to establish a shared secret using an
- Elliptic-Curve Diffie-Hellman key exchange. The initiator of that connection creates an ephemeral
+ 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 than send to the target peer. For any subsequent
- packet this procedure is repeated with a new ephemeral key. The wire format for such an KX packet can
+ 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"/>.
- The communicator always offers this kind of message queue to a (reachable) peer but it is inefficient
- since for every packet, a new key exchange is carried out. The performance of this queue is therefore
- not suitable for high-volume data transfer.
+ 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>
Should however the target peer acknowledge the reception of a KX packet the resulting key can be re-used.
