[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0007] branch master updated (f755dc2 -> 5e74e23)
|
From: |
gnunet |
|
Subject: |
[lsd0007] branch master updated (f755dc2 -> 5e74e23) |
|
Date: |
Wed, 19 Jun 2024 12:48:55 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a change to branch master
in repository lsd0007.
from f755dc2 update tcp
new c7503e5 cleanup some udp
new 5cc9711 more cleanup
new 85a2f1f more tcp cleanup
new cb0da35 minor
new 5e74e23 repr
The 5 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-gnunet-communicators.xml | 280 +++++++++++++++++++----------------------
1 file changed, 131 insertions(+), 149 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
index 6dac34d..f4282d6 100644
--- a/draft-gnunet-communicators.xml
+++ b/draft-gnunet-communicators.xml
@@ -40,7 +40,14 @@
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
-<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="info"
docName="draft-gnunet-communicators-00" ipr="trust200902" obsoletes=""
updates="" submissionType="IETF" xml:lang="en" version="3">
+<rfc xmlns:xi="http://www.w3.org/2001/XInclude";
+ category="info"
+ docName="draft-gnunet-communicators-00"
+ ipr="trust200902"
+ obsoletes="" updates=""
+ submissionType="independent"
+ xml:lang="en"
+ version="3">
<!-- xml2rfc v2v3 conversion 2.26.0 -->
<front>
<title abbrev="The GNUnet communicators">
@@ -71,6 +78,19 @@
<email>christian.grothoff@bfh.ch</email>
</address>
</author>
+ <author fullname="Pedram Fardzadeh" initials="P." surname="Fardzadeh">
+ <organization>Technischen Universität München</organization>
+ <address>
+ <postal>
+ <street>Boltzmannstrasse 3</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>DE</country>
+ </postal>
+ <email>pedram.fardzadeh@tum.de</email>
+ </address>
+ </author>
+
<!-- Meta-data Declarations -->
<area>General</area>
@@ -99,7 +119,6 @@
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
- FIXME
This document defines the normative wire format of resource
records, resolution processes, cryptographic routines and
security considerations for use by implementers.
@@ -125,7 +144,7 @@
<dl>
<dt>Communicator</dt>
<dd>
- FIXME This is a test
+ What is a communicator?
</dd>
</dl>
</section>
@@ -208,8 +227,6 @@
We use a hash-based key derivation function (HKDF) as defined in
<xref target="RFC5869" />, using SHA-256 <xref target="RFC6234"/> for
the extraction
phase and SHA-256 <xref target="RFC6234"/> for the expansion phase.
- </t>
- <t>
We define the key derivation function (KDF) used to derive a uniform
symmetric key
from the X25519 result "Z" and the ephemeral public key "A":
</t>
@@ -227,16 +244,6 @@ KDF(A,Z):
described in Section 5 of <xref target="BHKL13"/>.
</t>
<t>
-<<<<<<< HEAD
- Let G be the basepoint of Curve25519, EdToCurve() 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_PUB the ephemeral Curve25519
public key and EPH_SK the corresponding secret key. Observe that:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-(REC_SK, REC_ID) := KeyGenEd25519()
-(EPH_SK, EPH_PUB) := KeyGenCurve25519()
-Z := X25519(EPH_SK, EdToCurve25519(REC_ID)) = X25519(REC_SK, EPH_PUB)
-=======
Communicators use a modified version of the standard X25519 key
exchange described in
section 6.1 of <xref target="RFC7748"/>.
We refer to the the ephemeral key pair as "a" and "A := a*G" where G
is the generator of
@@ -246,6 +253,16 @@ Z := X25519(EPH_SK, EdToCurve25519(REC_ID)) =
X25519(REC_SK, EPH_PUB)
This use of a KEM and its safety has been investigated by <xref
target="T21"/>.
</t>
<t>
+ 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,
+ preventing communication between peers.
+ The communicators <bcp14>MAY</bcp14> use the Elligator KEM defined in
the following to produce random-looking
+ encapsulations (referred to as a "representative").
+ This leaves the attacker with the option to either do nothing or
intercept all random-looking UDP packets,
+ thereby potentially disrupting a large part of today's internet
communication.
+ </t>
+ <t>
Let G be the basepoint of Curve25519, EdToCurve() a function which
converts Ed25519 points to their corresponding Curve25519 points,
Enc() Elligator's encoding function,
Dec() Elligator's decoding function, "X" the receiver's peer identity
(a 256-bit EdDSA public key),
@@ -255,7 +272,6 @@ Z := X25519(EPH_SK, EdToCurve25519(REC_ID)) =
X25519(REC_SK, EPH_PUB)
(x, X) := KeyGenEd25519()
(a, A) := KeyGenX25519()
Z := X25519(a, EdToCurve(X)) = X25519(x, A)
->>>>>>> 75d0591 (update tcp)
]]></artwork>
<t>
We can then define the KEM:
@@ -266,19 +282,11 @@ EncapsElligator(X):
REPR := Enc(A, rand)
return REPR, MSK
-<<<<<<< HEAD
-Encaps(REC_ID):
- (EPH_SK, EPH_PUB) := KeyGenCurve25519()
- Z := X25519(EPH_SK, EdToCurve25519(REC_ID))
- MSK := KDF(EPH_PUB,Z)
- return EPH_PUB, MSK
-=======
Encaps(X):
(a, A) := KeyGenX25519()
Z := X25519(a, EdToCurve(X))
MSK := KDF(A,Z)
return A, MSK
->>>>>>> 75d0591 (update tcp)
]]></artwork>
<artwork anchor="decaps" name="" type="" align="left" alt=""><![CDATA[
DecapsElligator(x, REPR):
@@ -299,29 +307,35 @@ Decaps(x, A):
<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 message sent by the communicator
- is indistinguishable from random noise to an outside observer (FIXME: Not
the case for BROADCAST messages).
+ 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 message sent by the communicator
+ is indistinguishable from random payload to an outside observer, with the
exception of broadcast messages.
</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 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.
- 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
message.
+ For any new connection to a target peer, the communicator attempts to
establish a shared secret using the
+ KEM defined in <xref target="elligator_kem"/>.
+ The communicator initiating the connection sends the resulting Elligator
representative, the authentication tag
+ and the encrypted data to the receiving peer.
+ 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.
+ 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.
+ 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
+ to the receiving peer.
</t>
<t>
- 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 acknowledgment for a transmission. This queue is suitable for
high-volume data transfer, and TRANSPORT
- will prioritize it if available.
+ If the target peer is able to acknowledge 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
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.
@@ -332,20 +346,11 @@ Decaps(x, A):
<section anchor="Key_exchange" numbered="true" toc="default">
<name>Key exchange</name>
<t>
- 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 messages,
a key exchange is performed for every message.
- 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 (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 <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.
+ Independent of the type of message queue, a key exchange is initiated
at least once by the sending peer.
+ In cases where the receiving peer cannot acknowledge the reception of
messages, a key exchange is performed for every message.
+ Two key pairs are needed for the KEM: An ephemeral key pair generated
as part of the encapsulation procedure
+ "EncapsElligator" and the peer identity of the receiving communciator.
+ The encapsulation is transfered 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[
@@ -372,12 +377,11 @@ Decaps(x, A):
<dl>
<dt>REPRESENTATIVE</dt>
<dd>
- A serialized Elligator encoded 256-bit Curve25519 public key. This
encoded public key can be decoded and than used as part of an X25519-based
- key exchange to establish a shared secret.
+ The 256-bit serialized encapsulation result of the Elligator KEM.
</dd>
<dt>GCM TAG</dt>
<dd>
- A 128-bit GCM tag used to authenticate the ciphertext immediately
following the header part of the KX message.
+ The 128-bit GCM tag used to authenticate the ciphertext immediately
following the header part of the KX message.
</dd>
<dt>ENCRYPTED DATA</dt>
<dd>
@@ -387,16 +391,16 @@ Decaps(x, A):
</dl>
<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.
+ <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">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
-| SENDER PEER ID |
+| SENDER PEER ID |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -442,11 +446,10 @@ Decaps(x, A):
</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 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.">
+ <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
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -512,45 +515,48 @@ Decaps(x, A):
</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 the
Elligator KEM described in <xref target="primitives"/>. 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"/>.
+ Upon receiving a KX message, the receiving peer decapsulates the
respresentative using the "DecapsElligator"
+ procedure defined in <xref target="elligator_kem"/> and receives a
master secret key MSK.
+ 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"/>.
</t>
<t>
- The resulting MSK is used to derive symmetric encryption key K and
initialization vector IV using SetupCipher(MSQ,SEQ).
- 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).
+ The MSK is then used together with a sequence number SEQ to derive
symmetric encryption key K and initialization
+ vector IV using the "SetupCipher" procedure outlined below.
+ 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
+ the sequence number SEQ for SetupCipher(MSK, SEQ).
</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"/>.
+ Additional data might be inserted after the confirmation header as
part of the encrypted data of the KX message.
+ <!-- Wat? -->
+ 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
+ MSK to switch to a stable session.
+ The details about the acknowledgment process and subsequent message
exchange can be found in
+ <xref target="udp_message_exchange"/>.
</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).
- </t>
- <t>
- For SetupCipher, 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":
+ Once a shared secret MSK is established through the Elligator KEM, a
symmetric key and
+ initialization vector are derived.
+ According to a key schedule from a 32-bit sequence number SEQ (in
network byte order) and the MSK.
+ The initial value of the sequence number is 0.
</t>
<artwork anchor="setup_cipher" name="" type="" align="left"
alt=""><![CDATA[
SetupCipher(MSK,SEQ):
- PRK_h := HKDF-Extract (SEQ, MSK)
- K,IV := HKDF-Expand (PRK_h, "gnunet-communicator-udp-key-iv", 32 + 12)
+ PRK := HKDF-Extract (SEQ, MSK)
+ K,IV := HKDF-Expand (PRK, "gnunet-communicator-udp-key-iv", 44)
return K,IV
]]></artwork>
<t>
- With SetupCipher, a 256-bit AES key as well as a 96-bit IV for use in
AES-GCM
- are derived from the MSK and SEQ.
+ SetupCipher returns a 256-bit AES key "K" as well as a 96-bit "IV" for
use in AES-GCM.
</t>
<t>
Each derived key is uniquely identified using a separately derived
@@ -558,13 +564,13 @@ SetupCipher(MSK,SEQ):
</t>
<artwork anchor="derive_kid" name="" type="" align="left"
alt=""><![CDATA[
DeriveKID(MSK,SEQ):
- PRK_h := HKDF-Extract (SEQ, MSK)
- KID := HKDF-Expand (PRK_h, "gnunet-communicator-udp-kid", 256 / 8)
+ PRK := HKDF-Extract (SEQ, MSK)
+ KID := HKDF-Expand (PRK, "gnunet-communicator-udp-kid", 256 / 8)
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 senders side for each
+ successive encryption and on the receivers side for each decryption.
</t>
</section>
<section anchor="udp_message_exchange" numbered="true" toc="default">
@@ -752,20 +758,17 @@ DeriveKID(MSK,SEQ):
<section anchor="tcp_handshake" numbered="true" toc="default">
<name>Handshake</name>
<t>
- The main purpose of the handshake is to establish shared key material
for each direction of the communication
- channel. The initiating TCP Communicator starts the handshake by sending
an ephemeral Curve25519 public key,
- which is necessary to perform the X25519-based key exchange defined in
<xref target="tcp_KEM"/>. As the
- public key can not be encrypted at this stage of the communication
channel it <bcp14>MUST</bcp14> be encoded
- using the Elligator encoding function.
- In contrast to the plain public key, the encoded public key (also called
the representative) is indistinguishable
- from a random-looking byte stream, which protects against censors
targeting messages containing cryptographic
- material.
+ The main purpose of the handshake is to establish shared key material
for each direction of the communication
+ channel.
+ The initiating TCP Communicator starts the handshake by sending an
encapsulation from the Elligator KEM
+ defined in <xref target="elligator_kem"/>.
</t>
<t>
- The sent public key <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
this data is authenticated via a
- signature, which is also included in the TCP handshake message.
+ 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.
</t>
<figure anchor="figure_tcp_handshake" title="The binary representation
of the TCP handshake message.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -878,9 +881,7 @@ DeriveKID(MSK,SEQ):
</dd>
<dt>REPRESENTATIVE</dt>
<dd>
- A serialized Elligator encoded 256-bit Curve25519 public key. This
encoded
- public key can be decoded and than used as part of an X25519-based
key
- exchange to establish a shared secret.
+ The 256-bit serialized encapsulation result of the Elligator KEM.
</dd>
<dt>MONOTONIC TIMESTAMP</dt>
<dd>
@@ -1055,53 +1056,34 @@ DeriveKID(MSK,SEQ):
<section anchor="tcp_KEM" numbered="true" toc="default">
<name>Key exchange</name>
<t>
- During the initial handshake, each communication channel performs an
X25519-based KEM, which provides the key material
- for the use of AES-CTR and HMAC-SHA512. Later, further key exchanges are
performed during each rekeying process. More
- about the initial handshake and rekeying can be found in <xref
target="tcp_handshake"/> and
+ During the initial handshake, each communication channel performs the
Elligator KEM defined in
+ <xref target="elligator_kem"/>.
+ 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.
</t>
<t>
- The TCP communicator doesn't follow the standard X25519-KEM as described
in
- section 6.1 of <xref target="RFC7748"/> because Curve25519 public keys
are recognisable by an outside observer. In a
- censored environment, this could lead to the interception of such
messages and ultimately prevent communication
- between peers. We circumvent this issue by encoding public keys using
Elligator, a mathematical method to encode curve points
- into random-looking byte streams (referred to as the "representative").
- Since all data, apart from the public keys, is only sent encrypted, all
the data send over the communication channel
- is indistinguishable from a random byte stream. This forces a censor to
choose between taking no action or intercepting all
- random-looking TCP packets, thereby significantly disrupting a large
portion of modern internet communication.
- For more information about elligator and its usage, please refer to
<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_tcp"/>. We
can then define the TCP communicator’s key
- exchange as a KEM:
+ Let (REC_SK, REC_ID) be the receiver peer's EdDSA key pair.
+ The sender peer initiates the key exchange using the Elligator KEM from
<xref target="elligator_kem"/>
+ resulting in an encapsulation and initial master secret key MSK.
+ MSK is used to derive a symmetric encryption and HMAC key as well as an
initialization vector using
+ the procedure "SetupCipher":
</t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- (REC_SK, REC_ID) := KeyGenEd25519()
- # Sender calls
- REPR, MSK := EncapsElligator(REC_ID)
- # Receiver calls
- MSK := DecapsElligator(REC_SK, REPR)
- # Key derivation
- (K,IV,M_mac) := SetupCipher(REC_ID,MSK)
- ]]></artwork>
- <t>
- </t>
<artwork anchor="setup_cipher_tcp" name="" type="" align="left"
alt=""><![CDATA[
-SetupCipher(PEERID, MSK):
- PRK := HKDF-Extract (0, PEERID||MSK)
- K := HKDF-Expand (PRK, "gnunet-communicator-tcp-key", 256 / 8)
- IV := HKDF-Expand (PRK, "gnunet-communicator-tcp-ctr, 128 / 8)
- K_mac := HKDF-Expand (PRK, "gnunet-communicator-tcp-hmac, 512 / 8)
+SetupCipher(REC_ID, MSK):
+ PRK := HKDF-Extract (0, REC_ID||MSK)
+ K := HKDF-Expand (PRK, "gnunet-communicator-tcp-key", 32)
+ IV := HKDF-Expand (PRK, "gnunet-communicator-tcp-ctr, 16)
+ K_mac := HKDF-Expand (PRK, "gnunet-communicator-tcp-hmac, 64)
return K,IV,K_mac
]]></artwork>
<t>
- Note that the initiating TCP communicator can already perform the
encapsulation step after generating the ephemeral
- key pair and immediately encrypt the TCP handshake message before
sending it. As soon as the receiving TCP communicator
- receives and decodes the ephemeral public key, it can perform the
decapsulation step of the KEM and decrypt the
- following TCP handshake message. The same applies for the TCP
handshake message send by the receiving TCP communicator.
+ 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
+ following TCP handshake message.
+ The same applies for the TCP handshake message send by the receiving
TCP communicator.
</t>
</section>
<section anchor="tcp_message_exchange" numbered="true" toc="default">
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0007] branch master updated (f755dc2 -> 5e74e23),
gnunet <=
- [lsd0007] 05/05: repr, gnunet, 2024/06/19
- [lsd0007] 02/05: more cleanup, gnunet, 2024/06/19
- [lsd0007] 01/05: cleanup some udp, gnunet, 2024/06/19
- [lsd0007] 04/05: minor, gnunet, 2024/06/19
- [lsd0007] 03/05: more tcp cleanup, gnunet, 2024/06/19