commit fca456e2749b296d7c9d1cf5de1d7795e97ac163
parent d5a1da46d29db77e80e6d4860ac2d016a618d090
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Wed, 19 Jun 2024 00:47:06 +0200
Adjusted KEM text in UDP and TCP communicator
Diffstat:
1 file changed, 22 insertions(+), 39 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -236,13 +236,13 @@ KDF(A,Z):
described in Section 5 of <xref target="BHKL13"/>.
</t>
<t>
- Let G be the basepoint of Curve25519, Ed_To_Curve() a function which converts Ed25519 points to their corresponding Curve25519
+ 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_SK a 256-bit ephemeral secret key and SetupCipher() the HKDF defined in <xref target="setup_cipher"/>. Observe that:
+ 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) := KeyGenX25519()
+(EPH_SK, EPH_PUB) := KeyGenCurve25519()
Z := X25519(EPH_SK, EdToCurve25519(REC_ID)) = X25519(REC_SK, EPH_PUB)
]]></artwork>
<t>
@@ -255,7 +255,7 @@ EncapsElligator(REC_ID):
return REPR, MSK
Encaps(REC_ID):
- (EPH_SK, EPH_PUB) := KeyGenX25519()
+ (EPH_SK, EPH_PUB) := KeyGenCurve25519()
Z := X25519(EPH_SK, EdToCurve25519(REC_ID))
MSK := KDF(EPH_PUB,Z)
return EPH_PUB, MSK
@@ -494,21 +494,16 @@ Decaps(REC_SK, REPR):
</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"/>.
+ 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"/>.
</t>
- <t>
- The resulting MSK is used to derive symmetric encryption key K and initialization vector IV using SetupCipher(MSQ,SEQ).
+ <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).
</t>
- <t>
- 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"/>. It is also important to mention that the ephemeral public key, which is depicted in the KEM as G.EPH_SK, is
- a point on the whole Curve25519 and not restricted to its prime subgroup. This is due to the fact that Elligator's encoding function is
- defined on the whole Curve25519. The exclusive usage of the prime subgroup would restrict the set of potential representatives, which in
- turn an outside observer can trivially recognize.
- </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
@@ -1047,7 +1042,7 @@ DeriveKID(MSK,SEQ):
<xref target="tcp_rekeying"/> respectively.
</t>
<t>
- The TCPcommunicator doesn't follow the standard X25519-KEM as described in
+ 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
@@ -1058,19 +1053,16 @@ DeriveKID(MSK,SEQ):
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:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-Key_Gen() := (REC_SK, REC_ID)
-Encap(REC_ID) := (REPR, (K,IV,K_mac)) = (Enc(G.EPH_SK, rand), SetupCipher(KDF(X25519(EPH_SK, Ed_To_Curve(REC_ID)))))
-Decap(REPR) := (K,IV, K_mac) = SetupCipher(X25519(REC_SK, Dec(REPR)))
- ]]></artwork>
- <t>
- </t>
+ The UDP communicator utilizes the Elligator KEM described in <xref target="primitives"/>. The KEM is performed for each
+ communication direction. Note that the exchange of the receiver peer identity is not within the scope of the TCP
+ 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>
+ Once the shared secret MSK is established, the initial key material for the usage of AES-CTR and HMAC is setup. While AES-CTR
+ just needs to be setup once for encrypting an arbitrary amount of data, new HMAC key material is generated through ratcheting.
+ The setup process for establishing the initial key material from the MSK looks as follows:
+ </t>
<artwork anchor="setup_cipher_tcp" name="" type="" align="left" alt=""><![CDATA[
SetupCipher(MSK):
PRK := HKDF-Extract (0, PEERID||MSK)
@@ -1085,15 +1077,6 @@ SetupCipher(MSK):
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.
</t>
- <t>
- Similarly to the usage of Elligator in the UDP communicator, it's important to note that in the TCP communicator, the
- exchange of receiver peer identity is not part of the key exchange scope and is assumed to be known to the sending peer.
- Additionally, the ephemeral public key utilized in the key exchange process, represented as G.EPH_SK, resides on the entire
- Curve25519, not solely within its prime subgroup. This decision is driven by Elligator's encoding function, which operates
- across the entire Curve25519. Exclusively using the prime subgroup would limit the potential representatives, allowing an
- outside observer to easily recognize them. As mentioned beforehand, the usage of peer identities for both Ed25519 signatures
- and X25519-based KEM is proven to be secure. For more comprehensive information, please refer to the paper [T21].
- </t>
</section>
<section anchor="tcp_message_exchange" numbered="true" toc="default">
<name>Message exchange</name>
@@ -1427,7 +1410,7 @@ Dec(REPR):
return X
]]></artwork>
<t>
- Note that both for the a value REPR and its negative counterpart -REPR (in the finite field), the decoding function will result in the
+ Note that both for a value REPR and its negative counterpart -REPR (in the finite field), the decoding function will result in the
same x-coordinate. Moreover, for two different valid x-coordinates the resulting representatives are different. Conversely,
this means that we can't decode both representatives back to their original x-coordinate. This effectivly reduces the entropy of our
public keys by 1 bit, which is torelable. With this in mind, the sender need test that the generated ephemeral public key result in the
