commit e88cda15136afccfa7c863acc18fe251950cc3d3
parent 9ca2823171093a53c692682b56e5804b9f3740f7
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 16 Jul 2024 23:44:05 +0200
trying to order the chaos again
Diffstat:
1 file changed, 110 insertions(+), 93 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -221,14 +221,7 @@
</t>
</section>
<section anchor="primitives" numbered="true" toc="default">
- <name>Cryptographic primitives</name>
- <section anchor="KeyGen" numbered="true" toc="default">
- <name>Key generation</name>
- <t>
- Let "KeyGenEd25519() -> (x,X)" denote a function that produces an Ed25519 key pair as defined in <xref target="RFC8032"/>.
- Let "KeyGenX25519() -> (x,X)" denote a function that produces an X25519 key pair as defined in <xref target="RFC7748"/>.
- Let "KeyGenElligator() -> (x,X)" denote a function that produces a Curve25519 key pair suitable for Elligator obfuscations which we will define in the following.
- </t>
+ <name>Cryptographic dependencies</name>
<t>
GNUnet communicators utilize Elligator for the encoding and decoding of the ephemeral public keys
described in Section 5 of <xref target="BHKL13"/>.
@@ -241,28 +234,55 @@
for which this property holds.
One heurisitic is to generate random key pairs until one such point is found.
</t>
+ <section anchor="elligator_dhkem" numbered="true" toc="default">
+ <name>Elligator DHKEM</name>
+ <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 UDP and TCP communicators 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 packets,
+ thereby potentially disrupting a large part of today's internet communication.
+ </t>
+ <t>
+ We define our KEMs analoguous to <xref target="RFC9180"/> Section 4.
+ The <tt>kem_id</tt> in the <tt>suite_id</tt> for the Elligator KEM is <tt>256</tt> (NOTE: This value is not registered in IANA yet).
+ </t>
+ <t>
+ The value of <tt>suite_id</tt> depends on the KEM used. The <tt>ExtractAndExpand()</tt>, <tt>Encap()</tt>
+ and <tt>Decap()</tt> functions are used as defined in <xref target="RFC9180"/> for standard DHKEMs.
+ The communicators use the standard <tt>DHKEM(X25519, HKDF-SHA256)</tt> and a special Elligator-based KEM
+ defined below.
+ </t>
+ <section anchor="elligator_dhkem_keygen" numbered="true" toc="default">
+ <name>GenerateKeyPair()</name>
<t>
Let G be the generator of the prime order group of Ed25519, H the generator of the low order subgroup of
Ed25519 and EdToCurve() a function which converts Ed25519 points to their corresponding Curve25519 points.
We define "KeyGenElligator" as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-GenerateElligatorKeyPair():
+GenerateKeyPair():
VALID := 0
while(!VALID):
- x := random(256)
- x[0] &= 248
- x[31] &= 127
- x[31] |= 64
- E_high := x * G
- E_low := (x mod 8) * H
+ skX := random(256)
+ skX[0] &= 248
+ skX[31] &= 127
+ skX[31] |= 64
+ E_high := skX * G
+ E_low := (skX mod 8) * H
E := E_high + E_low
- X := EdToCurve(E)
- if ElligatorDec(ElligatorEnc(X)) == X:
- return (x,X)
+ pkX := EdToCurve(E)
+ if ElligatorDec(ElligatorEnc(pkX)) == pkX:
+ return (skX,pkX)
]]></artwork>
+ </section>
+ <section anchor="elligator_dhkem_serialize" numbered="true" toc="default">
+ <name>SerializePublicKey()</name>
<t>
- "ElligatorEnc()" and "ElligatorDec()" are the required encoding and decoding functions to obfuscate a curve
+ The serialization functions incorporate the Elligator encoding and decoding functions to obfuscate a curve
point and are are defined in the following.
The obfuscated curve point is called the Elligator "Representative".
Let A and P be the parameters for Curve25519 as specified in section 4.1 of <xref target="RFC7748"/>.
@@ -279,25 +299,29 @@ GenerateElligatorKeyPair():
The encoding function algorithm is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-SerializeElligatorPublicKey(X):
+SerializeElligatorPublicKey(pkX):
B := random(1)
if B == 1:
- R := sqrt(-X / ((X + A) * U))
+ pkXm := sqrt(-X / ((X + A) * U))
else:
- R := sqrt(-(X + A) / (U * X))
- return R
+ pkXm := sqrt(-(X + A) / (U * X))
+ return pkXm
]]></artwork>
+ </section>
+ <section anchor="elligator_dhkem_deserialize" numbered="true" toc="default">
+ <name>DeserializePublicKey()</name>
<t>
The corresponding decoding agorithm is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
-DeserializeElligatorPublicKey(R):
+DeserializeElligatorPublicKey(pkXm):
V := -A / (1 + U * R^2)
E := L(V^3 + A * V^2 + V)
- X := E * V - (1 - E)(A / 2)
- return X
+ pkX := E * V - (1 - E)(A / 2)
+ return pkX
]]></artwork>
</section>
+ </section>
<section anchor="key_derivation" numbered="true" toc="default">
<name>Key derivation</name>
<t>
@@ -307,65 +331,14 @@ DeserializeElligatorPublicKey(R):
We derive the master secret as a uniform symmetric key
from the X25519 result "Z" and the ephemeral public key "A" in a
"HKDF-Extract" step and then derive context-specific keys through "HKDF-Expand" as needed.
- </t>
- </section>
- <section anchor="elligator_kem" numbered="true" toc="default">
- <name>Key encapsulation</name>
- <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 UDP and TCP communicators 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 packets,
- thereby potentially disrupting a large part of today's internet communication.
- </t>
- <t>
- We define our KEMs analoguous to <xref target="RFC9180"/> Section 4 with modified static labels for domain separation from
- the HPKE use case:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-def LabeledExtract(salt, label, ikm):
- labeled_ikm = concat("gnunet-kem-v1", suite_id, label, ikm)
- return Extract(salt, labeled_ikm)
-
-def LabeledExpand(prk, label, info, L):
- labeled_info = concat(I2OSP(L, 2), "gnunet-kem-v1", suite_id,
- label, info)
- return Expand(prk, labeled_info, L)
- ]]></artwork>
- <t>
- The value of <tt>suite_id</tt> depends on the KEM used. The <tt>ExtractAndExpand()</tt>, <tt>Encap()</tt>
- and <tt>Decap()</tt> functions are used as defined in <xref target="RFC9180"/> for standard DHKEMs.
- The communicators use the standard <tt>DHKEM(X25519, HKDF-SHA256)</tt> and a special Elligator-based KEM
- defined below.
- </t>
- <t>
- Let G be the basepoint of Curve25519, EdToCurve() a function which converts Ed25519 points to their corresponding Curve25519 points,
- ElligatorEnc() Elligator's encoding function,
- ElligatorDec() Elligator's decoding function, "X" the receiver's peer identity (a 256-bit EdDSA public key),
- "x" the corresponding secret key,
- "A" an ephemeral public key (256-bit Curve25519 public key) and
- "a" the corresponding 256-bit ephemeral secret key. Observe that:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-(x, X) := KeyGenEd25519()
-(a, A) := KeyGenElligator()
-Z := X25519(a, EdToCurve(X)) = X25519(x, A)
- ]]></artwork>
- <t>
- The only changes required in an Elligator-based KEM are that drop-in replacements of
- <tt>GenerateKeyPair() -> GenerateElligatorKeyPair()</tt>,
- <tt>SerializePublicKey() -> SerializeElligatorPublicKey()</tt>
- and <tt>DeserializePublicKey() -> DeserializeElligatorPublicKey</tt> functions.
</t>
<t>
- More details about the construction of the representative and Elligator's
- usage can be found in <xref target="KeyGen"/>.
+ Peer IDs in GNUnet are Ed25519 public keys as defined <xref target="RFC8032"/>.
+ In order to use such keys in our X25519-based KEMs (including the Elligator KEM), those
+ keys must be converted to Curve25519 public keys, which is generally possible.
</t>
- </section>
- </section>
+ </section>
+ </section>
<section anchor="udp_comm" numbered="true" toc="default">
<name>UDP communicator</name>
<t>
@@ -375,7 +348,7 @@ Z := X25519(a, EdToCurve(X)) = X25519(x, A)
</t>
<t>
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"/>.
+ KEM defined in <xref target="elligator_dhkem"/>.
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,
@@ -578,7 +551,7 @@ Z := X25519(a, EdToCurve(X)) = X25519(x, A)
</dl>
<t>
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.
+ procedure defined in <xref target="elligator_dhkem"/> 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
@@ -895,7 +868,7 @@ DeriveKID(MSK,SEQ):
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"/>.
+ 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
@@ -1191,7 +1164,7 @@ DeriveKID(MSK,SEQ):
<name>Key exchange</name>
<t>
During the initial handshake, each communication channel performs the Elligator KEM defined in
- <xref target="elligator_kem"/>.
+ <xref target="elligator_dhkem"/>.
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
@@ -1199,7 +1172,7 @@ DeriveKID(MSK,SEQ):
</t>
<t>
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"/>
+ The sender peer initiates the key exchange using the Elligator KEM from <xref target="elligator_dhkem"/>
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":
@@ -1573,14 +1546,44 @@ SetupCipher(REC_ID, MSK):
<name>GANA Considerations</name>
</section>
<!-- gana -->
- <!--<section>
+ <section>
<name>IANA Considerations</name>
<t>
- This document makes no requests for IANA action.
- This section may be removed on publication as an RFC.
+ This document defines a new KEM as allowed in <xref target="RFC9180"/>.
+ It is requested that the "HPKE KEM Identifiers" registry is updated with
+ the values from <xref target="kemid-values"/>.
+ This section may be removed on publication as an RFC.
</t>
- </section>
- <section>
+ <table anchor="kemid-values" align="center" pn="table-2">
+ <name slugifiedName="name-kem-ids">KEM IDs</name>
+ <thead>
+ <tr>
+ <th align="left" colspan="1" rowspan="1">Value</th>
+ <th align="left" colspan="1" rowspan="1">KEM</th>
+ <th align="left" colspan="1" rowspan="1">Nsecret</th>
+ <th align="left" colspan="1" rowspan="1">Nenc</th>
+ <th align="left" colspan="1" rowspan="1">Npk</th>
+ <th align="left" colspan="1" rowspan="1">Nsk</th>
+ <th align="left" colspan="1" rowspan="1">Auth</th>
+ <th align="left" colspan="1" rowspan="1">Reference</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td align="left" colspan="1" rowspan="1">0x0120</td>
+ <td align="left" colspan="1" rowspan="1">DHKEM(X25519Elligator, HKDF-SHA256)</td>
+ <td align="left" colspan="1" rowspan="1">32</td>
+ <td align="left" colspan="1" rowspan="1">32</td>
+ <td align="left" colspan="1" rowspan="1">32</td>
+ <td align="left" colspan="1" rowspan="1">32</td>
+ <td align="left" colspan="1" rowspan="1">no</td>
+ <td align="left" colspan="1" rowspan="1">
+ <xref target="LSD0007"/></td>
+ </tr>
+ </tbody>
+ </table>
+ </section>
+ <!-- <section>
<name>Implementation and Deployment Status</name>
<t>
FIXME
@@ -1635,7 +1638,21 @@ SetupCipher(REC_ID, MSK):
<date month="August" year="2013" />
</front>
</reference>
- </references>
+ <reference anchor="LSD0007" target="https://lsd.gnunet.org/lsd0007">
+ <front>
+ <title>The GNUnet communicators</title>
+ <author initials="M" surname="Schanzenbach"
+ fullname="Martin Schanzenbach">
+ </author>
+ <author initials="C." surname="Grothoff"
+ fullname="Christian Grothoff">
+ </author>
+ <author initials="P." surname="Fardzadeh"
+ fullname="Pedram Fardzadeh">
+ </author>
+ <date month="July" year="2024" />
+ </front>
+ </reference> </references>
<section>
