lsd0007

LSD0007: GNUnet communicators
Log | Files | Refs

commit 2d534a9728b1f7058db1bd12bbc6d1c6a466a19b
parent dba8e77640c7c7fda541c2139ff0401545a9db99
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Sat, 27 Jul 2024 12:54:38 +0200

improve naming

Diffstat:
Mdraft-gnunet-communicators.xml | 84+++++++++++++++++++++++++++++++++++++++++++++++++------------------------------
1 file changed, 52 insertions(+), 32 deletions(-)

diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml @@ -149,7 +149,21 @@ </dd> </dl> </section> - <section anchor="overview" numbered="true" toc="default"> + <section> + <name>Notation</name> + <t> + We use the notation from <xref target="RFC9180"/> and <xref target="LSD0011"/>. + In addition, we define: + </t> + <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; + skXed is the Ed25519 private key and pkXed is the Ed25519 public key as defined in + <xref target="RFC8032"/>. + </dd> + </dl> + </section> <section anchor="overview" numbered="true" toc="default"> <name>Overview</name> <t> Each communicator must specify its (global) communication characteristics, @@ -303,14 +317,19 @@ 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"/>. + <tt>Encap(pkR) -> (MSK,enc)</tt> and the peer identity of the receiving communciator. + The algorithm in use for the KEM is <tt>DHKEM(X25519+Elligator, HKDF-SHA256)</tt> <xref target="LSD0011"/>. + The peer identity of the receiving communicator is an Ed25519 public key <tt>pkRed</tt>. + 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"/>. </t> <figure anchor="figure_udp_initialkx" title="The binary representation of the KX message."> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 8 16 24 +-----+-----+-----+-----+-----+-----+-----+-----+ -| REPRESENTATIVE | +| ENC | | | | | | | @@ -329,9 +348,9 @@ ]]></artwork> </figure> <dl> - <dt>REPRESENTATIVE</dt> + <dt>ENC</dt> <dd> - The 256-bit serialized encapsulation result of the Elligator KEM. + The 256-bit serialized encapsulation result <tt>enc</tt> of the KEM. </dd> <dt>GCM TAG</dt> <dd> @@ -383,7 +402,7 @@ <dl> <dt>SENDER PEER ID</dt> <dd> - A 256-bit EdDSA public key. + A 256-bit EdDSA public key (<tt>pkSed</tt>). </dd> <dt>SIGNATURE</dt> <dd> @@ -419,7 +438,7 @@ | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ -| EPHEMERAL PUBLIC KEY | +| ENC | | | | | | | @@ -452,16 +471,15 @@ </dd> <dt>SENDER PEER ID</dt> <dd> - A 256-bit EdDSA public key. + A 256-bit EdDSA public key (<tt>pkSed</tt>). </dd> <dt>RECEIVER PEER ID</dt> <dd> - A 256-bit EdDSA public key. + A 256-bit EdDSA public key (<tt>pkRed</tt>). </dd> - <dt>EPHEMERAL PUBLIC KEY</dt> + <dt>ENC</dt> <dd> - A 256-bit Curve25519 public key. This public key is send in an Elligator encoded format, called - the representative, in the KX header. + The 256-bit serialized encapsulation result <tt>enc</tt> of the KEM. </dd> <dt>MONOTONIC TIMESTAMP</dt> <dd> @@ -469,8 +487,10 @@ </dd> </dl> <t> - Upon receiving a KX message, the receiving peer decapsulates the respresentative using the "DecapsElligator" - procedure defined in <xref target="elligator_dhkem"/> and receives a master secret key MSK. + Upon receiving a KX message, the receiving peer decapsulates the secret key <tt>MSK</tt> using + <tt>MSK &lt;- Decap(skR,enc)</tt>, where <tt>skR</tt> is the X25519 private key derived from + its Ed25519 counterpart <tt>skRed</tt>. + 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 @@ -645,7 +665,8 @@ DeriveKID(MSK,SEQ): 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 - ephemeral public key is encrypted, there is no need to use Elligator's encoding function. The wire format of the Rekey header can + ephemeral public key is encrypted, there is no need to use Elligator's encoding function and we use the normal, unobfuscated + <tt>DHKEM(X25519, HKDF-SHA256)</tt>. The wire format of the Rekey header can be seen in <xref target="figure_udp_rekey"/>. </t> <figure anchor="figure_udp_rekey" title="The wire format of a Rekey header."> @@ -654,7 +675,7 @@ DeriveKID(MSK,SEQ): +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | TYPE (0x0X) | +-----+-----+-----+-----+-----+-----+-----+-----+ -| EPHEMERAL PUBLIC KEY | +| ENC | | | | | | | @@ -674,9 +695,9 @@ DeriveKID(MSK,SEQ): <dd> A 16-bit signature type flag in network byte order. The value of this field MUST be 1462. </dd> - <dt>EPHEMERAL PUBLIC KEY</dt> + <dt>ENC</dt> <dd> - A 256-bit X25519 ephemeral public key to rekey with. + The 256-bit serialized encapsulation result <tt>enc</tt> of the KEM. </dd> </dl> <t> @@ -712,7 +733,7 @@ DeriveKID(MSK,SEQ): <dl> <dt>SENDER PEER ID</dt> <dd> - A 256-bit EdDSA public key. + A 256-bit EdDSA public key (<tt>pkSed</tt>). </dd> <dt>SIGNATURE</dt> <dd> @@ -755,7 +776,7 @@ DeriveKID(MSK,SEQ): </dd> <dt>SENDER PEER ID</dt> <dd> - A 256-bit EdDSA public key. + A 256-bit EdDSA public key (<tt>pkSed</tt>). </dd> <dt>ADDRESS HASH</dt> <dd> @@ -826,7 +847,7 @@ DeriveKID(MSK,SEQ): <dl> <dt>SENDER PEER ID</dt> <dd> - A 256-bit EdDSA public key. + A 256-bit EdDSA public key (<tt>pkSed</tt>). </dd> <dt>SIGNATURE</dt> <dd> @@ -907,7 +928,7 @@ DeriveKID(MSK,SEQ): </dd> <dt>REPRESENTATIVE</dt> <dd> - The 256-bit serialized encapsulation result of the Elligator KEM. + The 256-bit serialized encapsulation result of the KEM. </dd> <dt>MONOTONIC TIMESTAMP</dt> <dd> @@ -1193,7 +1214,7 @@ SetupCipher(REC_ID, MSK): | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ -| EPHEMERAL PUBLIC KEY | +| ENC | | | | | | | @@ -1232,10 +1253,9 @@ SetupCipher(REC_ID, MSK): A 256-bit HMAC-SHA512 hashcode of this TCP Rekey message. The hashcode is computed with the hashcode field initially set to zero and is inserted afterward. </dd> - <dt>EPHEMERAL PUBLIC KEY</dt> + <dt>ENC</dt> <dd> - A 256-bit Curve25519 public key which is used as part of an X25519-based - key exchange to establish a shared secret. + The 256-bit serialized encapsulation result <tt>enc</tt> of the KEM. </dd> <dt>Signature</dt> <dd> @@ -1263,7 +1283,7 @@ SetupCipher(REC_ID, MSK): | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ -| EPHEMERAL PUBLIC KEY | +| ENC | | | | | | | @@ -1296,15 +1316,15 @@ SetupCipher(REC_ID, MSK): </dd> <dt>SENDER PEER ID</dt> <dd> - A 256-bit EdDSA public key. + A 256-bit EdDSA public key (<tt>pkSed</tt>). </dd> <dt>RECEIVER PEER ID</dt> <dd> - A 256-bit EdDSA public key. + A 256-bit EdDSA public key (<tt>pkRed</tt>). </dd> - <dt>EPHEMERAL PEER ID</dt> + <dt>ENC</dt> <dd> - A 256-bit EdDSA public key. + The 256-bit serialized encapsulation result <tt>enc</tt> of the KEM. </dd> <dt>MONOTONIC TIMESTAMP</dt> <dd>