draft-schanzen-hpke-elligator-kem.xml (26814B)
1 <?xml version='1.0' encoding='utf-8'?> 2 <!DOCTYPE rfc [ 3 <!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml"> 4 <!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml"> 5 <!ENTITY RFC1928 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml"> 6 <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> 7 <!--<!ENTITY RFC2693 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2693.xml">--> 8 <!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml"> 9 <!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"> 10 <!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml"> 11 <!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml"> 12 <!ENTITY RFC4033 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml"> 13 <!ENTITY RFC5237 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5237.xml"> 14 <!--<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">--> 15 <!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> 16 <!ENTITY RFC5895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml"> 17 <!ENTITY RFC6066 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml"> 18 <!ENTITY RFC6761 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml"> 19 <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml"> 20 <!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml"> 21 <!ENTITY RFC7363 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7363.xml"> 22 <!ENTITY RFC8806 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8806.xml"> 23 <!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml"> 24 <!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> 25 <!ENTITY RFC8174 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> 26 <!ENTITY RFC8244 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8244.xml"> 27 <!ENTITY RFC8324 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml"> 28 <!ENTITY RFC8499 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml"> 29 <!ENTITY RFC9106 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9106.xml"> 30 <!ENTITY RFC9180 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9180.xml"> 31 <!ENTITY I-D.ietf-dnsop-alt-tld PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-alt-tld.xml"> 32 ]> 33 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 34 <?rfc strict="yes" ?> 35 <?rfc toc="yes" ?> 36 <?rfc symrefs="yes"?> 37 <?rfc sortrefs="yes" ?> 38 <?rfc compact="yes" ?> 39 <?rfc subcompact="no" ?> 40 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" 41 category="info" 42 docName="draft-schanzen-hpke-elligator-kem-00" 43 ipr="trust200902" 44 obsoletes="" updates="" 45 submissionType="independent" 46 xml:lang="en" 47 version="3"> 48 <!-- xml2rfc v2v3 conversion 2.26.0 --> 49 <front> 50 <title abbrev="The HPKE Elligator KEM"> 51 The HPKE Elligator KEM 52 </title> 53 <seriesInfo name="Internet-Draft" value="draft-schanzen-hpke-elligator-kem-00"/> 54 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 55 <organization>Fraunhofer AISEC</organization> 56 <address> 57 <postal> 58 <street>Lichtenbergstrasse 11</street> 59 <city>Garching</city> 60 <code>85748</code> 61 <country>DE</country> 62 </postal> 63 <email>martin.schanzenbach@aisec.fraunhofer.de</email> 64 </address> 65 </author> 66 <author fullname="Pedram Fardzadeh" initials="P." surname="Fardzadeh"> 67 <organization>Technische Universität München</organization> 68 <address> 69 <postal> 70 <street>Boltzmannstrasse 3</street> 71 <city>Garching</city> 72 <code>85748</code> 73 <country>DE</country> 74 </postal> 75 <email>pedram.fardzadeh@tum.de</email> 76 </address> 77 </author> 78 79 80 <!-- Meta-data Declarations --> 81 <area>General</area> 82 <workgroup>Independent Stream</workgroup> 83 <keyword>transport protocols</keyword> 84 <abstract> 85 <t> 86 This document contains the GNUnet communicator 87 specification. 88 </t> 89 <t> 90 This document defines the normative wire format of communicator protocols, 91 cryptographic routines and security 92 considerations for use by implementers. 93 </t> 94 <t> 95 This specification was developed outside the IETF and does not have 96 IETF consensus. It is published here to inform readers about the 97 function of GNUnet communicators, guide future communicator implementations, and ensure 98 interoperability among implementations including with the pre-existing 99 GNUnet implementation. 100 </t> 101 </abstract> 102 </front> 103 <middle> 104 <section anchor="introduction" numbered="true" toc="default"> 105 <name>Introduction</name> 106 <t> 107 Diffie-Hellman-based KEMs (DHKEMs) allow us to securely establish a secret between two parties. 108 However, an observer can quickly identify the exchanged encapsulation in DHKEMs as public keys. 109 In the presence of a passive eavesdropping attacker, packets could drop based on this information, 110 preventing communication between peers as outlined in <xref target="BHKL13"/>. 111 The presented solution in <xref target="BHKL13"/> is called "Elligator" and allows us to produce random-looking 112 representations of curve points. 113 This leaves an attacker with fewer options: either do nothing or intercept most random-looking packets, 114 thereby potentially disrupting a large part of today's internet communication. 115 </t> 116 <t> 117 In the case of Montgomery curves, such as Curve25519, a point [X, Y] on that curve (e.g., the ephemeral public key) follows the equation 118 <tt>Y^2 = X^3 + A * X^2 + X mod P</tt>, where A and P are parameters for Curve25519 specified in Section 4.1 of <xref target="RFC7748"/>. For any 119 valid x-coordinate, the left side of the equation is always a quadratic number. An attacker could read the x-coordinate 120 and verify if this property holds. While this property holds for any valid Curve25519 point, it only holds for a 121 random number in about 50% of the cases. By observing multiple communication attempts, an attacker can be sure that curve points are being sent if the property consistently holds. 122 To circumvent this attack, curve points should be encoded into property-less numbers, making valid and invalid curve points indistinguishable 123 to an outside observer. 124 The Elligator encoding function (also known as the "inverse map") and decoding function (also known as the "direct map") implement this feature. 125 </t> 126 <t> 127 In this document, we define and use an Elligator transformation for X25519 curve points based on the Curve25519 transformations 128 in <xref target="BHKL13"/> to be used in a Key Encapsulation Mechanim (KEM) for use 129 in HPKE <xref target="RFC9180"/> 130 and its security considerations for use by implementers. 131 </t> 132 <t> 133 This specification was developed outside the IETF and does not have 134 IETF consensus. It is published here to guide implementers 135 and ensure interoperability among implementations. 136 </t> 137 <section numbered="true" toc="default"> 138 <name>Requirements Notation</name> 139 <t> 140 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only 144 when, they appear in all capitals, as shown here. 145 </t> 146 </section> 147 </section> 148 <section anchor="notation" numbered="true" toc="default"> 149 <name>Notation</name> 150 <t> 151 We use the notation and terminology of <xref target="RFC9180"/> throughout 152 this document. 153 In addition, we define: 154 </t> 155 <dl> 156 <dt>coinFlip()</dt> 157 <dd> 158 A helper function that returns "heads" or "tails". Each result is 159 returned with a likelihood of 50%. 160 </dd> 161 </dl> </section> 162 <section anchor="elligator_dhkem" numbered="true" toc="default"> 163 <name>Elligator DHKEM</name> 164 <t> 165 The Elligator HPKE DHKEM utilizes Elligator to encode and decode the ephemeral public keys 166 as described in Section 5 of <xref target="BHKL13"/>. 167 We define our KEM analogous to <xref target="RFC9180"/> Section 4. 168 The <tt>kem_id</tt> in the <tt>suite_id</tt> for the Elligator KEM is <tt>TBD</tt> 169 </t> 170 <t> 171 The <tt>ExtractAndExpand()</tt>, <tt>Encap()</tt> 172 and <tt>Decap()</tt> functions (and their authenticated variants) can remain unchanged and <bcp14>MUST</bcp14> be 173 implemented as defined in Section 4.1 of <xref target="RFC9180"/>. 174 The serialization functions <tt>SerializePublicKey</tt> and <tt>DeserializePublicKey</tt> are defined in the following for Curve25519. 175 </t> 176 <section anchor="elligator_dhkem_keygen" numbered="true" toc="default"> 177 <name>GenerateKeyPair()</name> 178 <t> 179 First, not all X25519 key pairs are suitable candidates for Elligator. 180 In particular, not all Curve25519 points have the property that the Elligator encoding and subsequent 181 decoding result in the original point (See <xref target="security_elligator"/> for details). 182 To create a Curve25519 point that can be used with Elligator, one needs to find a curve point 183 for which this property holds. 184 When generating a key pair suitable for Elligator, the general idea is to create both a random high-order point and a low-order point. 185 Adding them together results in a curve point that is evenly distributed on the whole curve. 186 One heuristic is to generate random key pairs until one such point is found: 187 </t> 188 <t> 189 Let <tt>G</tt> be the generator of the prime order group of Ed25519 and <tt>H</tt> the generator of the low order subgroup of 190 Ed25519. 191 <tt>EdToCurve()</tt> is a function that converts Ed25519 points to their corresponding Curve25519 points. 192 We define "GenerateElligatorKeyPair()" as follows: 193 </t> 194 <artwork name="" type="" align="left" alt=""><![CDATA[ 195 GenerateElligatorKeyPair(): 196 VALID := 0 197 while(!VALID): 198 skX := random(Nsk) 199 skX[0] &= 24 200 skX[31] &= 127 201 skX[31] |= 64 202 E_high := skX * G 203 E_low := (skX mod 8) * H 204 E := E_high + E_low 205 pkX := EdToCurve(E) 206 if ElligatorDec(ElligatorEnc(pkX)) == pkX: 207 return (skX,pkX) 208 ]]></artwork> 209 <t> 210 We operate on the Edwards representation for the key generation because the necessary 211 low-order point additions are more efficient in most implementations than they would be in their Montgomery form. 212 A conversion from Edwards to their birationally equivalent Montgomery form is always possible and found in 213 most cryptographic library implementations. 214 </t> 215 <t> 216 The <tt>GenerateKeyPair</tt> algorithm <bcp14>MUST</bcp14> be implemented to produce a key pair suitable for 217 Elligator. 218 The <tt>GenerateElligatorKeyPair()</tt> algorithm defined here is <bcp14>RECOMMENDED</bcp14>. 219 Other, more efficient key generation algorithms <bcp14>MAY</bcp14> be used. 220 </t> 221 </section> 222 <section anchor="elligator_dhkem_serialize" numbered="true" toc="default"> 223 <name>SerializePublicKey()</name> 224 <t> 225 The serialization functions incorporate the Elligator inverse and direct map functions to obfuscate a curve 226 point. 227 The Elligator literature calls the obfuscated curve point a "representative". In the following, the "representative" 228 is named pkXm, where X stands for any of the roles defined in <xref target="RFC9180"/>. 229 </t> 230 <t> 231 Let <tt>A</tt> and <tt>P</tt> be the parameters for Curve25519 as specified in section 4.1 of <xref target="RFC7748"/>. 232 Further, let <tt>X</tt> be any valid x-coordinate of a Curve25519 point, <tt>L()</tt> a function that computes the 233 Legendre symbol of a field element with regard to the odd prime <tt>P</tt>. 234 Let <tt>sqrt()</tt> denote the square root operation within the field. As each square number has two roots, we need to 235 define the notion of positive and negative numbers. There are multiple valid ways to partition the field 236 elements. For this Elligator, we follow the recommendations of the paper in section 5.1 of <xref target="BHKL13"/> and 237 choose <tt>{0,..., (P-1)/2}</tt> as the set of positive numbers, and consequently <tt>{(P-1)/2 + 1,...,P-1}</tt> as the 238 set of the negative numbers. Both Elligator's inverse and direct map require us to define a constant non-square number 239 of the finite field. Let <tt>U := sqrt(-1)</tt> be this number. 240 The resulting serialization algorithm for the HPKE KEM can then be described as: 241 </t> 242 <artwork name="" type="" align="left" alt=""><![CDATA[ 243 SerializeElligatorPublicKey(pkX): 244 if coinFlip() == 1: 245 pkXm := sqrt(-pkX / ((pkX + A) * U)) 246 else: 247 pkXm := sqrt(-(pkX + A) / (U * X)) 248 if coinFlip() == 1: 249 pkXm[31] |= 128 250 if coinFlip() == 1: 251 pkXm[31] |= 64 252 return pkXm 253 ]]></artwork> 254 <t> 255 Note that SerializeElligatorPublicKey(pkX) represents Elligator's inverse map 256 with a slight modification: The resulting representative of the inverse map is strictly smaller than 2^254 - 9. Therefore, 257 the most and second most significant bits are always zero, an obvious property an attacker could observe. We avoid this 258 problem by randomly flipping both bits. The target peer will ignore these bits after reception by setting those bits back to zero. 259 Similarly, as there are always two roots for each square number, we randomly select one or the other upon each serialization. 260 </t> 261 </section> 262 <section anchor="elligator_dhkem_deserialize" numbered="true" toc="default"> 263 <name>DeserializePublicKey()</name> 264 <artwork name="" type="" align="left" alt=""><![CDATA[ 265 DeserializeElligatorPublicKey(pkXm): 266 pkXm[31] &= 63 267 V := -A / (1 + U * pkXm^2) 268 E := L(V^3 + A * V^2 + V) 269 pkX := E * V - (1 - E)(A / 2) 270 return pkX 271 ]]></artwork> 272 <t> 273 Note that DeserializeElligatorPublicKey(pkX) represents Elligator's direct map. 274 We must, and can safely, clear the most and second most significant bits that were set randomly as 275 elaborated above before reconstructing the square root. 276 </t> 277 </section> 278 </section> 279 <section anchor="security" numbered="true" toc="default"> 280 <name>Security and Privacy Considerations</name> 281 <section anchor="security_elligator" numbered="true" toc="default"> 282 <name>Elligator</name> 283 <t> 284 Most modern implementations of Curve25519 only generate points from its prime 285 subgroup to circumvent known attacks for which points not within the prime subgroup are susceptible. Those attacks are not an 286 issue in our case as we use the ephemeral secret key only once for computing key material. The exclusive use of the prime subgroup is a recognizable 287 property that an outside observer can easily detect, even when using the encoding function. An attacker could decode the suspected 288 parts of packets to the corresponding Curve25519 points and check if the resulting points are always in the prime subgroup. To circumvent 289 this attack, we must randomly choose the ephemeral key pair from the whole curve as defined in "GenerateElligatorKeyPair()". 290 </t> 291 <t> 292 The intuition behind elligator is based on the following idea: The direct map (here DeserializeElligatorPublicKey(r)) 293 expects a random field element r. The value r is mapped to two values, for which only one coordinate is a valid Curve25519 x-coordinate. 294 One can show the pair of values V_1 := -A / (1 + U * r^2) and V_2 := -A * U * r^2 (1 + U * r^2) always fulfill this property, 295 based on the fact that U is a non-square number in the field. The direct map first computes V_1 and checks if V_1 fulfills the curve 296 equation. If it does, it returns V_1; otherwise, V_2 is computed and returned instead. The inverse map, 297 (here SerializeElligatorPublicKey(V)) reverses this process and computes the corresponding field element of a valid x-coordinate. 298 Note that for encode and decode public keys, we reverse the call order of the direct and inverse map: First, 299 the inverse map is called on the ephemeral public key to retrieve the representative r. This representative is then send to the 300 receiving peer, who calls the direct map to retrieve the corresponding public key. 301 </t> 302 <t> 303 Note that both for a value r and its negative counterpart -r (in the finite field), the inverse map function will result in the same 304 x-coordinate. Moreover, for two different valid x-coordinates, the resulting representatives of the corresponding encoding calls are 305 different. Conversely, we can't decode both representatives back to their original x-coordinate. This is why the sender 306 eventually tries several random key pairs in GenerateElligatorKeyPair() to create a valid public key that can be used 307 for a key exchange. Also note that this effectively reduces the entropy of our public keys by 1 bit, which is tolerable. 308 </t> 309 <t> 310 In <xref target="BHKL13"/>, Elligator's inverse map takes the sign of y-coordinate as an additional input parameter. Its value determines 311 which of the two terms is used instead of our random selection. Due to 312 known attacks, we also skip the calculation of the corresponding y-coordinate in the decoding function. 313 We omitted the y-coordinate part of both functions because Curve25519 points are solely represented by their x-coordinate in modern cryptosystems. 314 Nevertheless, the desired feature of Elligator is still ensured. 315 </t> 316 </section> 317 <section anchor="security_aead" numbered="true" toc="default"> 318 <name>Combination with AEAD Encryption</name> 319 <t> 320 When using the Elligator KEM in combination with AEAD encryption schemes, care must be taken to ensure that the 321 ciphertext produced by the AEAD cipher is also indistinguishable from random. 322 The AEAD schemes listed in <xref target="RFC9180"/> use GCM and Poly1305 authentication tags, which 323 should result in ciphertexts that are indistinguishable from random. 324 However, future AEAD schemes and, in particular, their authenticators may not exhibit the same 325 cryptographic properties. 326 This should be considered when assembling HPKE suites with the Elligator KEM. 327 </t> 328 </section> 329 </section> 330 <!-- gana --> 331 <section> 332 <name>IANA Considerations</name> 333 <t> 334 The "HPKE KEM Identifiers" registry was amended with 335 the values from <xref target="kemid-values"/>. 336 </t> 337 <table anchor="kemid-values" align="center"> 338 <name slugifiedName="name-kem-ids">KEM IDs</name> 339 <thead> 340 <tr> 341 <th align="left" colspan="1" rowspan="1">Value</th> 342 <th align="left" colspan="1" rowspan="1">KEM</th> 343 <th align="left" colspan="1" rowspan="1">Nsecret</th> 344 <th align="left" colspan="1" rowspan="1">Nenc</th> 345 <th align="left" colspan="1" rowspan="1">Npk</th> 346 <th align="left" colspan="1" rowspan="1">Nsk</th> 347 <th align="left" colspan="1" rowspan="1">Auth</th> 348 <th align="left" colspan="1" rowspan="1">Reference</th> 349 </tr> 350 </thead> 351 <tbody> 352 <tr> 353 <td align="left" colspan="1" rowspan="1">0x0022</td> 354 <td align="left" colspan="1" rowspan="1">DHKEM(X25519+Elligator, HKDF-SHA256)</td> 355 <td align="left" colspan="1" rowspan="1">32</td> 356 <td align="left" colspan="1" rowspan="1">32</td> 357 <td align="left" colspan="1" rowspan="1">32</td> 358 <td align="left" colspan="1" rowspan="1">32</td> 359 <td align="left" colspan="1" rowspan="1">yes</td> 360 <td align="left" colspan="1" rowspan="1"> 361 This.I-D</td> 362 </tr> 363 </tbody> 364 </table> 365 </section> 366 <section> 367 <name>Implementation and Deployment Status</name> 368 <t> 369 There is one implementation conforming to this specification, written in C. 370 The implementation is part of <xref target="GNUnet"/> and represents the original and reference implementation. 371 </t> 372 <t> 373 The basic Elligator primitives GenerateKeyPair(), SerializePublicKey() and DeserializePublicKey() 374 are present in <xref target="GNUnetElligator"/>. The corresponding KEM primitives are part of <xref target="GNUnetHPKE"/>. 375 </t> 376 </section> 377 <!-- <section> 378 <name>Acknowledgements</name> 379 <t> 380 FIXME 381 </t> 382 </section> --> 383 </middle> 384 <back> 385 <references> 386 <name>Normative References</name> 387 &RFC2119; 388 &RFC7748; 389 &RFC8174; 390 &RFC9180; 391 392 </references> 393 <references> 394 <name>Informative References</name> 395 <reference anchor="BHKL13" target="https://eprint.iacr.org/2013/325.pdf"> 396 <front> 397 <title>Elligator: Elliptic-curve points indistinguishable from uniform random strings</title> 398 <author initials="D.J" surname="Bernstein" 399 fullname="Daniel J. Bernstein"> 400 </author> 401 <author initials="M." surname="Hamburg" 402 fullname="Mike Hamburg"> 403 </author> 404 <author initials="A." surname="Krasnova" 405 fullname="Anna Krasnova"> 406 </author> 407 <author initials="T." surname="Lange" 408 fullname="Tanja Lange"> 409 </author> 410 <date month="August" year="2013" /> 411 </front> 412 </reference> 413 <!--<reference anchor="LSD0007" target="https://lsd.gnunet.org/lsd0007"> 414 <front> 415 <title>The GNUnet communicators</title> 416 <author initials="M" surname="Schanzenbach" 417 fullname="Martin Schanzenbach"> 418 </author> 419 <author initials="C." surname="Grothoff" 420 fullname="Christian Grothoff"> 421 </author> 422 <author initials="P." surname="Fardzadeh" 423 fullname="Pedram Fardzadeh"> 424 </author> 425 <date month="July" year="2024" /> 426 </front> 427 </reference>--> 428 <reference anchor="GNUnet" target="https://git.gnunet.org/gnunet.git"> 429 <front> 430 <title>gnunet.git - GNUnet core repository</title> 431 <author initials="GNUnet e.V." surname="" 432 fullname=""> 433 </author> 434 <date month="" year="2023" /> 435 </front> 436 </reference> 437 <reference anchor="GNUnetElligator" target="https://git.gnunet.org/gnunet.git/tree/src/lib/util/crypto_elligator.c"> 438 <front> 439 <title>gnunet.git - Elligator primitives implementation in GNUnet core repository</title> 440 <author initials="M" surname="Schanzenbach" 441 fullname="Martin Schanzenbach"> 442 </author> 443 <author initials="P." surname="Fardzadeh" 444 fullname="Pedram Fardzadeh"> 445 </author> 446 <date month="" year="2023" /> 447 </front> 448 </reference> 449 <reference anchor="GNUnetHPKE" target="https://git.gnunet.org/gnunet.git/tree/src/lib/util/crypto_hpke.c"> 450 <front> 451 <title>gnunet.git - HPKE Primitive implementation in GNUnet core repository</title> 452 <author initials="M" surname="Schanzenbach" 453 fullname="Martin Schanzenbach"> 454 </author> 455 <author initials="P." surname="Fardzadeh" 456 fullname="Pedram Fardzadeh"> 457 </author> 458 <date month="" year="2023" /> 459 </front> 460 </reference> 461 </references> 462 463 464 <section> 465 <name>Elligator implementation</name> 466 <t> 467 This section provides a test vector for the Elligator KEM and should aid in verifying implementations. 468 Note that Elligator has two parameters: the set of positive and negative numbers, and a non-square number U 469 within the finite field, as described in section 5.1 of <xref target="BHKL13"/>. The displayed test vectors assume that the set of positive 470 numbers is defined as {0,...,(P-1)/2}, the set of negative numbers as {(P-1)/2 + 1,...,P−1} and U is the non-square number 471 sqrt(-1). The depicted coin flips are used in the order of the coinFlip() calls in SerializeElligatorPublicKey(pkX), namely 472 coin flip 1 for choosing the pkXm term, coin flip 2 for the MSB and coin flip 3 for the second MSB. 473 Unless indicated otherwise, the test vectors are provided as little-endian hexadecimal byte arrays. 474 </t> 475 <section> 476 <name>Elligator KEM</name> 477 <artwork name="" type="" align="left" alt=""><![CDATA[ 478 coin flip 1: 0 479 coin flip 2: 1 480 coin flip 3: 1 481 pkEm: 482 3f73ee0dd1970ff957f7ec15e0b5151166be3046e6a8b0ee53beca395b74e42c 483 484 skEm: 485 09395966d6d1c493b9917dd12c8dd24e2c05c081c98a67eb2d6dff622ec9c069 486 487 skRm: 488 f33887a8562dad5151e9289a0afa1301ccc698917850d56ea409a9949497baa4 489 490 pkRm: 491 3febadac122d397725ff580f6ce9a3e1c1c4a7de19807f13d383f2f9b6467136 492 493 enc: 494 da0f7edaefed18a99f0b73a789e51c4c6e80664190ae3c8ae4e95b9d926a34f7 495 496 key: 497 46eff65b5313f41fbaffc7adf98f5df03ab4e4f46ae62a2c7ecbe1f0ae83280b 498 ]]></artwork> 499 </section> 500 </section> 501 </back> 502 </rfc>