[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0007] branch master updated: spelling error
|
From: |
gnunet |
|
Subject: |
[lsd0007] branch master updated: spelling error |
|
Date: |
Mon, 12 Aug 2024 13:27:43 +0200 |
This is an automated email from the git hooks/post-receive script.
pedram pushed a commit to branch master
in repository lsd0007.
The following commit(s) were added to refs/heads/master by this push:
new 8403a27 spelling error
8403a27 is described below
commit 8403a27d942f5179b77b29c4c78e869084169a13
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
AuthorDate: Mon Aug 12 13:27:33 2024 +0200
spelling error
---
draft-gnunet-communicators.xml | 126 ++++++++++++++++++++---------------------
1 file changed, 63 insertions(+), 63 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
index 1d070d0..694e30c 100644
--- a/draft-gnunet-communicators.xml
+++ b/draft-gnunet-communicators.xml
@@ -126,7 +126,7 @@
</t>
<t>
This specification was developed outside the IETF and does not have
- IETF consensus. It is published here to guide implementers of GNS
+ IETF consensus. It is published here to guide GNS implementers
and to ensure interoperability among implementations.
</t>
<section numbered="true" toc="default">
@@ -158,7 +158,7 @@
<dl>
<dt>(skXed, pkXed)</dt>
<dd>
- Akey pair used in role X, where X is one of S as sender or R as
recipient, respectively;
+ A key pair is used in role X, where X is one of S as sender or R as
recipient, respectively;
skXed is the Ed25519 private key and pkXed is the Ed25519 public key
as defined in
<xref target="RFC8032"/>.
</dd>
@@ -167,10 +167,10 @@
<name>Overview</name>
<t>
Each communicator must specify its (global) communication
characteristics,
- which for now only say whether the communication is reliable (e.g. TCP,
HTTPS)
- or unreliable (e.g. UDP, WLAN).
+ which for now only say whether the communication is reliable (e.g.,
TCP, HTTPS)
+ or unreliable (e.g., UDP, WLAN).
Each communicator must specify a unique address prex, or NULL if the
- communicator cannot establish outgoing connections (for example because
+ communicator cannot establish outgoing connections (for example, because
it is only acting as a TCP server).
A communicator must tell TRANSPORT which addresses it is reachable
under.
Addresses may be added or removed at any time.
@@ -203,13 +203,13 @@
</t>
<t>
The communicator API also provides for flow control.
- First, communicators exhibit back-pressure on TRANSPORT:
+ First, communicators exhibit backpressure on TRANSPORT:
the number of messages TRANSPORT may add to a queue for transmission
will
be limited.
- So by not draining the transmission queue, back-pressure is provided to
+ So, by not draining the transmission queue, backpressure is provided to
TRANSPORT.
In the other direction, communicators may allow TRANSPORT to give
- back-pressure towards the communicator by providing a non-NULL
+ backpressure towards the communicator by providing a non-NULL
GNUNET_TRANSPORT_MessageCompletedCallback argument to the
GNUNET_TRANSPORT_communicator_receive function.
In this case, TRANSPORT will only invoke this function once it has
@@ -218,7 +218,7 @@
this backpressure.
Note that communicators do not have to provide a
GNUNET_TRANSPORT_MessageCompletedCallback;
- for example, UDP cannot support back-pressure due to the nature of the
+ for example, UDP cannot support backpressure due to the nature of the
UDP protocol.
In this case, TRANSPORT will implement its own TRANSPORT-to-TRANSPORT
flow control to reduce the sender’s data rate to acceptable levels.
@@ -229,8 +229,8 @@
Similarly, communicators can ask TRANSPORT to try to send a backchannel
message to other communicators of other peers.
The semantics of the backchannel message are up to the communicators
- which use them.
- TRANSPORT may fail transmitting backchannel messages, and TRANSPORT will
+ who use them.
+ TRANSPORT may fail to transmit backchannel messages, and TRANSPORT will
not attempt to retransmit them.
</t>
</section>
@@ -243,7 +243,7 @@
the ephemeral public keys.
While standard Diffie-Hellman-based KEMs securely establish a secret
between
two parties, an observer can easily identify the encapsulation as a
public key.
- In the presence of an active attacker this could lead to packet
dropping based on this information,
+ In the presence of an active attacker, this could lead to packet
dropping based on this information,
preventing communication between peers.
The UDP and TCP communicators use the Elligator KEM defined in
<xref target="LSD0011"/>.
@@ -287,13 +287,13 @@
Since the GCM authentication tag and the encrypted data in the key exchange
message also appear random,
the entire message is computationally indistinguishable from a random byte
stream.
Independent of the payload, each message includes the sender's peer
identity, a monotonic timestamp, and a
- signature over the session meta data.
+ signature over the session metadata.
Receivers <bcp14>MUST</bcp14> keep track of the monotonic timestamps of key
exchanges with each peer
to prevent replay attacks.
- For each subsequent message the same procedure is conducted with a new
encapsulation.
+ For each subsequent message the same procedure is used with a new
encapsulation.
While the communicator may always fall back to this type of encryption, it
is inefficient for
high-volume data transfer because a new key exchange is required for every
message.
- However, sometimes we may have no other choice, for example if there is
only bi-directional connectivity
+ However, sometimes we may have no other choice, for example, if there is
only bi-directional connectivity
to the receiving peer.
</t>
<t>
@@ -323,7 +323,7 @@
In order to use it compliantly with a X25519-based DHKEM as defined in
<xref target="LSD0011"/> and <xref target="RFC9180"/>, the
curve point must first be converted from Edwards into its birationally
equivalent Montgomery form
<tt>pkR</tt>.
- The encapsulation <tt>enc</tt> is transfered via a key exchange (KX)
message as defined in <xref target="figure_udp_initialkx"/>.
+ The encapsulation <tt>enc</tt> is transferred via a key exchange (KX)
message, as defined in <xref target="figure_udp_initialkx"/>.
</t>
<figure anchor="figure_udp_initialkx" title="The binary representation
of the KX message.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -354,7 +354,7 @@
</dd>
<dt>GCM TAG</dt>
<dd>
- The 128-bit GCM tag used to authenticate the ciphertext immediately
following the header part of the KX message.
+ The 128-bit GCM tag is used to authenticate the ciphertext
immediately following the header part of the KX message.
</dd>
<dt>ENCRYPTED DATA</dt>
<dd>
@@ -365,8 +365,8 @@
<t>
In order to prevent replay attacks for KX messages, the plaintext
resulting from decryption of the encrypted data
<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.
+ It includes the sender's peer identity and a monotonic timestamp,
which the receiving peer <bcp14>MUST</bcp14>
+ keep track of each peer identity to reject possible replay attacks.
</t>
<figure anchor="figure_udp_confirmation" title="The binary representation of
the KX Confirmation header">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -407,11 +407,11 @@
<dt>SIGNATURE</dt>
<dd>
The EdDSA signature is computed with the peer private key
- over the session metadata as detailed in <xref
target="figure_udp_handshake_sig"/>.
+ over the session metadata, as detailed in <xref
target="figure_udp_handshake_sig"/>.
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds and
in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in microseconds
and in network byte order.
</dd>
<dt>PAYLOAD</dt>
<dd>
@@ -419,8 +419,8 @@
</dd>
</dl>
<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"/>
+ The confirmation header also includes a signature over the session's
metadata, which is signed with the corresponding private key of
+ the sender's 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[
@@ -465,7 +465,7 @@
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
the signature is created so that it cannot be reused in other parts
- of the protocol including possible future extensions.
+ of the protocol, including possible future extensions.
The value of this field corresponds to an entry in the
GANA "GNUnet Signature Purpose" registry <xref target="GANA"/>.
</dd>
@@ -483,7 +483,7 @@
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds
and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in
microseconds and in network byte order.
</dd>
</dl>
<t>
@@ -493,7 +493,7 @@
This <tt>Decap(skR, enc)</tt> procedure is defined in <xref
target="LSD0011"/>.
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
+ One way to exchange peer identities is through the UDP BROADCAST
messages as described in
<xref target="udp_bc"/>.
</t>
<t>
@@ -502,7 +502,7 @@
Both the sending and the receiving peer <bcp14>SHOULD</bcp14> store
the master shared secret MSK and attribute
it to the corresponding peer.
<!-- FIXME SEQ is increased by ACKs! -->
- In case of an acknowledgment from the receiving peer, the established
MSK can be reused by iterativly increasing
+ In case of an acknowledgment from the receiving peer, the established
MSK can be reused by iteratively increasing
the sequence number SEQ for SetupCipher(MSK, SEQ).
</t>
<t>
@@ -542,19 +542,19 @@ DeriveKID(MSK,SEQ):
return KID
]]></artwork>
<t>
- The sequence number SEQ for any shared secret is initially 0 and
incremented on the senders side for each
- successive encryption and on the receivers side for each decryption.
+ The sequence number SEQ for any shared secret is initially 0 and
incremented on the sender side for each
+ successive encryption and on the receiver side for each decryption.
</t>
</section>
<section anchor="udp_message_exchange" numbered="true" toc="default">
<name>Message exchange</name>
<t>
- KX messages as presented in <xref target="Key_exchange"/> are
sufficient for transferring arbitrary amounts of data. This way of
- communicating is slow, due to the establishment of a shared secret for
each message using asymmetric cryptography. The UDP communicator
- offers a faster way of communication with the reuse of a shared secret.
For this purpose, the receiver of a message <bcp14>SHOULD</bcp14>
+ KX messages, as presented in <xref target="Key_exchange"/>, are
sufficient for transferring arbitrary amounts of data. This way of
+ communicating is slow due to the establishment of a shared secret for
each message using asymmetric cryptography. The UDP communicator
+ offers a faster way of communicating by reusing 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 master shared secret and
+ sent 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 message.">
@@ -639,7 +639,7 @@ DeriveKID(MSK,SEQ):
</dd>
<dt>SEQ ACK</dt>
<dd>
- Sequence acknowledgment limit. Specifies current maximum sequence
number supported by receiver.
+ Sequence acknowledgment limit. Specifies the current maximum
sequence number supported by the receiver.
</dd>
<dt>MSK HASH</dt>
<dd>
@@ -661,7 +661,7 @@ DeriveKID(MSK,SEQ):
<section anchor="udp_rekeying" numbered="true" toc="default">
<name>Rekeying</name>
<t>
- The amount of data which can be encrypted with a shared secret
<bcp14>MUST</bcp14> be limited. Before
+ The amount of data that can be encrypted with a shared secret
<bcp14>MUST</bcp14> be limited. Before
the capacity of a shared secret is used up, the sender initiates
rekeying by sending a new ephemeral public key
for a key exchange. As multiple shared secrets can be used
simultaneously, rekeying doesn't necessarily delete the old shared secret if
its
capacity is not yet reached. The ephemeral public key is sent encrypted
in a Rekey header as part of the payload of BOX message. Because the
@@ -738,7 +738,7 @@ DeriveKID(MSK,SEQ):
<dt>SIGNATURE</dt>
<dd>
The EdDSA signature is computed with the announced peer private key
- over the peer identity and address hash as depicted in <xref
target="figure_udp_broadcast_sig"/>.
+ over the peer identity and address hash, as depicted in <xref
target="figure_udp_broadcast_sig"/>.
</dd>
</dl>
<figure anchor="figure_udp_broadcast_sig" title="The wire format of the
data structure over which the signature of the UDP BROADCAST message is
computed.">
@@ -770,7 +770,7 @@ DeriveKID(MSK,SEQ):
A 32-bit signature purpose flag in network byte order. The value of
this
field <bcp14>MUST</bcp14> be 34. 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.
+ of the protocol, including possible future extensions.
The value of this field corresponds to an entry in the
GANA "GNUnet Signature Purpose" registry <xref target="GANA"/>.
</dd>
@@ -791,8 +791,8 @@ DeriveKID(MSK,SEQ):
TCP communicators always establish an encrypted and bi-directional
communication channel. For
each direction of communication, a dedicated shared secret is used to
both encrypt and
authenticate messages. These shared secrets are exchanged during the
initial handshake. After a
- certain amount of data has been transmitted, re-keying occurs to renew
the key material.
- Note that the re-keying process is triggered individually for each
communication direction.
+ certain amount of data has been transmitted, rekeying occurs to renew
the key material.
+ Note that the rekeying process is triggered individually for each
communication direction.
</t>
<t>
To achieve a zero-plaintext design, we <bcp14>MUST</bcp14> use the
mac-then-encrypt approach to
@@ -811,11 +811,11 @@ DeriveKID(MSK,SEQ):
defined in <xref target="elligator_dhkem"/>.
</t>
<t>
- The encapsulation <bcp14>MUST</bcp14> be directly followed by an
encrypted TCP handshake message as shown in
+ The encapsulation <bcp14>MUST</bcp14> be directly followed by an
encrypted TCP handshake message, as shown in
<xref target="figure_tcp_handshake"/>.
In addition to the peer identity of the sender and a timestamp, it
contains a nonce as a challenge for the
receiving TCP communicator.
- All data is authenticated with signature.
+ All data is authenticated with a signature.
</t>
<figure anchor="figure_tcp_handshake" title="The binary representation
of the TCP handshake message.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -856,7 +856,7 @@ DeriveKID(MSK,SEQ):
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds
and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in
microseconds and in network byte order.
</dd>
<dt>NONCE</dt>
<dd>
@@ -914,7 +914,7 @@ DeriveKID(MSK,SEQ):
A 32-bit signature purpose flag in network byte order. The value of
this
field <bcp14>MUST</bcp14> be 31. 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.
+ of the protocol, including possible future extensions.
The value of this field corresponds to an entry in the
GANA "GNUnet Signature Purpose" registry <xref target="GANA"/>.
</dd>
@@ -932,7 +932,7 @@ DeriveKID(MSK,SEQ):
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds
and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in
microseconds and in network byte order.
</dd>
<dt>NONCE</dt>
<dd>
@@ -1020,7 +1020,7 @@ DeriveKID(MSK,SEQ):
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds
and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in
microseconds and in network byte order.
</dd>
<dt>NONCE</dt>
<dd>
@@ -1087,7 +1087,7 @@ DeriveKID(MSK,SEQ):
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds
and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in
microseconds and in network byte order.
</dd>
<dt>NONCE</dt>
<dd>
@@ -1108,7 +1108,7 @@ DeriveKID(MSK,SEQ):
The resulting shared secret us used in an AES-CTR encryption with
HMAC-SHA512.
Subsequent key exchanges are performed with each rekeying.
More about the initial handshake and rekeying can be found in <xref
target="tcp_handshake"/> and
- <xref target="tcp_rekeying"/> respectively.
+ <xref target="tcp_rekeying"/>, respectively.
</t>
<t>
Let (REC_SK, REC_ID) be the receiver peer's EdDSA key pair.
@@ -1127,24 +1127,24 @@ SetupCipher(REC_ID, MSK):
<t>
Note that the initiating TCP communicator can immediately encrypt the
first TCP handshake message when
sending it.
- As soon as the receiving TCP communicator receives and decapsulates the
repsentative, it can decrypt the
+ As soon as the receiving TCP communicator receives and decapsulates the
representative, it can decrypt the
following TCP handshake message.
- The same applies for the TCP handshake message send by the receiving
TCP communicator.
+ The same applies to the TCP handshake message sent by the receiving TCP
communicator.
</t>
</section>
<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
- consists of a TCP BOX message as defined in <xref
target="figure_tcp_box"/>, followed by the payload. Both parts are encrypted
+ Once the handshake is completed, actual payloads can be exchanged
bi-directionally using TCP BOX messages. A TCP Box message
+ consists of a TCP BOX message, as defined in <xref
target="figure_tcp_box"/>, followed by the payload. Both parts are encrypted
before being sent to the receiving peer.
</t>
<t>
TCP Box messages follow the mac-then-encrypt approach to hide the size of
the payload and achieve a zero-plaintext design.
The HMAC utilizes SHA512 as the underlying hash function and is ratcheted
after each operation. Given the mac-then-encrypt
- approach, additional safeguards are needed to protect against oracle
padding attacks. Therefore, we <bcp14>MUST</bcp14> use
- a padding free encryption scheme such as AES-CTR for encryption.
Additionally, we restrict the attacker's ability for replay
- attacks by exchanging new key material after a randomly chosen amount of
transferred data as described in
+ approach, additional safeguards are needed to protect against Oracle
padding attacks. Therefore, we <bcp14>MUST</bcp14> use
+ a padding-free encryption scheme such as AES-CTR for encryption.
Additionally, we restrict the attacker's ability to replay
+ attacks by exchanging new key material after a randomly chosen amount of
transferred data, as described in
<xref target="tcp_rekeying"/>. The necessary key exchanges to establish
the new key material are protected using monotonic
timestamps.
</t>
@@ -1192,11 +1192,11 @@ SetupCipher(REC_ID, MSK):
one day, rekeying is set off anyway.
</t>
<t>
- The receiving communicator is signaled about a rekeying through the
dispatch of a TCP Rekey message as defined in
+ The receiving communicator is signaled about a rekeying through the
dispatch of a TCP Rekey message, as defined in
<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 the rekeying
process doesn't involve an acknowledgment by the receiver of
+ is used to perform a key exchange from which new key material for the
encryption and authentication code scheme is derived. For further
+ 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.">
@@ -1264,7 +1264,7 @@ SetupCipher(REC_ID, MSK):
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds
and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in
microseconds and in network byte order.
</dd>
</dl>
<figure anchor="figure_tcp_rekey_sig" title="The wire format used for
creating the signature of the TCP Rekey message.">
@@ -1310,7 +1310,7 @@ SetupCipher(REC_ID, MSK):
A 32-bit signature purpose flag in network byte order. The value of
this
field <bcp14>MUST</bcp14> be 32. 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.
+ of the protocol, including possible future extensions.
The value of this field corresponds to an entry in the
GANA "GNUnet Signature Purpose" registry <xref target="GANA"/>.
</dd>
@@ -1328,7 +1328,7 @@ SetupCipher(REC_ID, MSK):
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
- A 64-bit value for absolute time used by GNUnet, in microseconds
and in network byte order.
+ A 64-bit value for the absolute time used by GNUnet, in
microseconds and in network byte order.
</dd>
</dl>
</section>
@@ -1402,7 +1402,7 @@ SetupCipher(REC_ID, MSK):
A 32-bit signature purpose flag in network byte order. The value of
this
field <bcp14>MUST</bcp14> be XXXX. 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.
+ of the protocol, including possible future extensions.
The value of this field corresponds to an entry in the
GANA "GNUnet Signature Purpose" registry <xref target="GANA"/>.
</dd>
@@ -1421,9 +1421,9 @@ SetupCipher(REC_ID, MSK):
<t>
Communicators use a modified version of the standard X25519 key
exchange described in
section 6.1 of <xref target="RFC7748"/>.
- It deviates in that we use the Ed25519 key pair "x","X = x*G" of the
peer identity as X25519 scalars
+ It deviates in that we use the Ed25519 key pair "x","X = x*G" of the
peer identity as X25519 scalars
and curve points, respectively.
- This use of a KEM and its safety has been investigated by <xref
target="T21"/>.
+ The safety of this use of a KEM has been investigated by <xref
target="T21"/>.
</t>
</section>
</section>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0007] branch master updated: spelling error,
gnunet <=