commit b41ec1d897284983e79266bc998c6021ec082b19
parent f657866388d4753c3b37d190975f23db60f659e3
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Fri, 21 Jun 2024 00:24:59 +0200
typos
Diffstat:
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -623,7 +623,7 @@ DeriveKID(MSK,SEQ):
</dd>
</dl>
<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
+ An acknowledgment 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 an
ACK header. The wire format of the ACK header can be seen in <xref target="figure_udp_ack"/>.
@@ -1153,7 +1153,7 @@ SetupCipher(REC_ID, MSK):
<xref target="figure_tcp_rekey"/>. The message <bcp14>MUST</bcp14> be encrypted with the current key. Due to the encryption of the message,
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 they rekeying process doesn't involve an acknowledgment by the receiver of
+ details please refer to <xref target="tcp_KEM"/>. Note that the rekeying process doesn't involve an acknowledgment by the receiver of
a TCP Rekey message. So the sender might send new payload encrypted by the new key right after sending the TCP Rekey message.
</t>
<figure anchor="figure_tcp_rekey" title="The binary representation of the TCP Rekey message.">
@@ -1379,7 +1379,7 @@ SetupCipher(REC_ID, MSK):
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.
+ random number. By observing multiple communication attempts, an attacker can be certain that curve points are being sent if the property consistently holds.
To circumvent this attack, curve points should be encoded into property-less numbers, making valid and invalid curve points indistinguishable
to an outside observer.
</t>
@@ -1389,7 +1389,7 @@ SetupCipher(REC_ID, MSK):
sqrt(-1) which is a non-quadratic number in the finite field, and legendre() a function which computes the legendre symbol of a field element.
As each of the field elements have two roots, we need to define the notion of negative and non-negative numbers. This is especially important for the
sqrt() function. A straightforward choice is to define the set {0,..., (P - 1) / 2} as set of all non-negative numbers.
- The encoding function used by both the UDP and TCP communicator can be defined as follows:
+ The encoding function used by the elligator encapsulation function in <xref target="encaps"/> can be defined as follows:
</t>
<artwork name="" type="" align="left" alt=""><