-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-irtf-cfrg-ristretto255-decaf448.xml
1178 lines (1017 loc) · 56.1 KB
/
draft-irtf-cfrg-ristretto255-decaf448.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-irtf-cfrg-ristretto255-decaf448-08" submissionType="IETF" category="info" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true" consensus="true">
<front>
<title abbrev="ristretto255-decaf448">The ristretto255 and decaf448 Groups</title><seriesInfo value="draft-irtf-cfrg-ristretto255-decaf448-08" stream="IETF" status="informational" name="Internet-Draft"></seriesInfo>
<author initials="H." surname="de Valence" fullname="Henry de Valence"><organization></organization><address><postal><street></street>
</postal><email>ietf@hdevalence.ca</email>
</address></author><author initials="J." surname="Grigg" fullname="Jack Grigg"><organization></organization><address><postal><street></street>
</postal><email>ietf@jackgrigg.com</email>
</address></author><author initials="M." surname="Hamburg" fullname="Mike Hamburg"><organization></organization><address><postal><street></street>
</postal><email>ietf@shiftleft.org</email>
</address></author><author initials="I." surname="Lovecruft" fullname="Isis Lovecruft"><organization></organization><address><postal><street></street>
</postal><email>ietf@en.ciph.re</email>
</address></author><author initials="G." surname="Tankersley" fullname="George Tankersley"><organization></organization><address><postal><street></street>
</postal><email>ietf@gtank.cc</email>
</address></author><author initials="F." surname="Valsorda" fullname="Filippo Valsorda"><organization></organization><address><postal><street></street>
</postal><email>ietf@filippo.io</email>
</address></author><date/>
<area>Internet</area>
<workgroup>Crypto Forum Research Group</workgroup>
<abstract>
<t>This memo specifies two prime-order groups, ristretto255 and decaf448,
suitable for safely implementing higher-level and complex
cryptographic protocols. The ristretto255 group can be implemented
using Curve25519, allowing existing Curve25519 implementations to be
reused and extended to provide a prime-order group. Likewise, the
decaf448 group can be implemented using edwards448.</t>
<t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
</abstract>
</front>
<middle>
<section anchor="introduction"><name>Introduction</name>
<t>Decaf <xref target="Decaf"></xref> is a technique for constructing prime-order groups
with non-malleable encodings from non-prime-order elliptic curves.
Ristretto extends this technique to support cofactor-8 curves such as
Curve25519 <xref target="RFC7748"></xref>. In particular, this allows an existing
Curve25519 library to provide a prime-order group with only a thin
abstraction layer.</t>
<t>Many group-based cryptographic protocols require the number of
elements in the group (the group order) to be prime. Prime-order
groups are useful because every non-identity element of the group
is a generator of the entire group. This means the group has a
cofactor of 1, and all elements are equivalent from the perspective
of Discrete Log Hardness.</t>
<t>Edwards curves provide a number of implementation benefits for
cryptography, such as complete addition formulas with no exceptional
points and formulas among the fastest known for curve operations.
However, the group of points on the curve is not of prime order,
i.e., it has a cofactor larger than 1.
This abstraction mismatch is usually handled by means of ad-hoc
protocol tweaks, such as multiplying by the cofactor in an
appropriate place, or not at all.</t>
<t>Even for simple protocols such as signatures, these tweaks can cause
subtle issues. For instance, Ed25519 implementations may have
different validation behavior between batched and singleton
verification, and at least as specified in <xref target="RFC8032"></xref>, the set of
valid signatures is not defined by the standard.</t>
<t>For more complex protocols, careful analysis is required as the
original security proofs may no longer apply, and the tweaks for one
protocol may have disastrous effects when applied to another (for
instance, the octuple-spend vulnerability in <xref target="MoneroVuln"></xref>).</t>
<t>Decaf and Ristretto fix this abstraction mismatch in one place for
all protocols, providing an abstraction to protocol implementors that
matches the abstraction commonly assumed in protocol specifications,
while still allowing the use of high-performance curve
implementations internally. The abstraction layer imposes minor
overhead, and only in the encoding and decoding phases.</t>
<t>While Ristretto is a general method, and can be used in conjunction
with any Edwards curve with cofactor 4 or 8, this document specifies
the ristretto255 group, which can be implemented using Curve25519,
and the decaf448 group, which can be implemented using edwards448.</t>
<t>There are other elliptic curves that can be used internally to
implement ristretto255 or decaf448, and those implementations would be
interoperable with a Curve25519- or edwards448-based one, but those
constructions are out-of-scope for this document.</t>
<t>The Ristretto construction is described and justified in detail at
<xref target="RistrettoGroup"></xref>.</t>
<t>This document represents the consensus of the Crypto Forum Research Group (CFRG).
This document is not an IETF product and is not a standard.</t>
</section>
<section anchor="notation-and-conventions-used-in-this-document"><name>Notation and Conventions Used In This Document</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>",
"<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref>
when, and only when, they appear in all capitals, as shown here.</t>
<t>Readers are cautioned that the term "Curve25519" has varying
interpretations in the literature, and that the canonical meaning of the
term has shifted over time. Originally it referred to a specific
Diffie-Hellman key exchange mechanism. Over time, use shifted, and
"Curve25519" has been used to refer to either the abstract underlying
curve, or its concrete representation in Montgomery form, or the
specific Diffie-Hellman mechanism. This document uses the term
"Curve25519" to refer to the abstract underlying curve, as recommended
in <xref target="Naming"></xref>. The abstract Edwards form of the curve we refer to here
as "Curve25519" is in <xref target="RFC7748"></xref> referred to as "edwards25519"
and its isogenous Montgomery form is referred to as "curve25519".</t>
<t>Elliptic curve points in this document are represented in extended
Edwards coordinates in the <tt>(x, y, z, t)</tt> format <xref target="Twisted"></xref>, also called
extended homogeneous coordinates in Section 5.1.4 of <xref target="RFC8032"></xref>. Field
elements are values modulo p, the Curve25519 prime 2^255 - 19 or the
edwards448 prime 2^448 - 2^224 - 1, as specified in Sections 4.1 and
4.2 of <xref target="RFC7748"></xref>, respectively. All formulas specify field operations
unless otherwise noted. The symbol ^ denotes exponentiation.</t>
<t>The <tt>|</tt> symbol represents a constant-time logical OR.</t>
<t>The notation <tt>array[A:B]</tt> means the elements of <tt>array</tt> from <tt>A</tt>
to <tt>B-1</tt>. That is, it is exclusive of <tt>B</tt>. Arrays are indexed
starting from 0.</t>
<t>A byte is an 8-bit entity (also known as "octet") and a byte string
is an ordered sequence of bytes. An N-byte string is a byte string of
N bytes in length.</t>
<t>Element encodings are presented as hex encoded byte strings with
whitespace added for readability.</t>
<section anchor="negative-field-elements"><name>Negative field elements</name>
<t>As in <xref target="RFC8032"></xref>, given a field element e, define <tt>IS_NEGATIVE(e)</tt> as
TRUE if the least non-negative integer representing e is odd, and
FALSE if it is even. This <bcp14>SHOULD</bcp14> be implemented in constant time.</t>
</section>
<section anchor="constant-time-operations"><name>Constant time operations</name>
<t>We assume that the field element implementation supports the following
operations, which <bcp14>SHOULD</bcp14> be implemented in constant time:</t>
<ul spacing="compact">
<li><tt>CT_EQ(u, v)</tt>: return TRUE if u = v, FALSE otherwise.</li>
<li><tt>CT_SELECT(v IF cond ELSE u)</tt>: return v if cond is TRUE, else return u.</li>
<li><tt>CT_ABS(u)</tt>: return -u if IS_NEGATIVE(u), else return u.</li>
</ul>
<t>Note that <tt>CT_ABS</tt> <bcp14>MAY</bcp14> be implemented as:</t>
<artwork><![CDATA[CT_SELECT(-u IF IS_NEGATIVE(u) ELSE u)
]]>
</artwork>
</section>
</section>
<section anchor="interface"><name>The group abstraction</name>
<t>Ristretto and Decaf implement an abstract prime-order group interface
that exposes only the behavior that is useful to higher-level protocols,
without leaking curve-related details and pitfalls.</t>
<t>Each abstract group exposes operations on abstract element and abstract
scalar types. The operations defined on these types include: decoding, encoding,
equality, addition, negation, subtraction and (multi-)scalar multiplication.
Each abstract group also exposes a deterministic function to derive abstract
elements from fixed-length byte strings. A description of each of these
operations is below.</t>
<t>Decoding is a function from byte strings to abstract elements with
built-in validation, so that only the canonical encodings of valid
elements are accepted. The built-in validation avoids the need for
explicit invalid curve checks.</t>
<t>Encoding is a function from abstract elements to byte strings. Internally,
an abstract element might have more than one possible representation -- for
example, the implementation might use projective coordinates. When encoding,
all equivalent representations of the same element are encoded as identical
byte strings. Decoding the output of the encoding function always
succeeds and returns an equivalent element to the encoding input.</t>
<t>The equality check reports whether two representations of an abstract
element are equivalent.</t>
<t>The element derivation function maps deterministically from byte strings of
a fixed length to abstract elements. It has two important properties. First,
if the input is a uniformly random byte string, then the output is (within
a negligible statistical distance of) a uniformly random abstract group
element. This means the function is suitable for selecting random group
elements.</t>
<t>Second, although the element derivation function is many-to-one and therefore
not strictly invertible, it is not pre-image resistent. On the contrary,
given an arbitrary abstract group element <tt>P</tt>, there is an efficient algorithm
to randomly sample from byte strings that map to <tt>P</tt>. In some contexts this
property would be a weakness, but it is important in some contexts: in particular,
it means that a combination of a cryptographic hash function and the element
derivation function is suitable for use in algorithms such as
<tt>hash_to_curve</tt> <xref target="draft-irtf-cfrg-hash-to-curve-16"></xref>.</t>
<t>Addition is the group operation. The group has an identity element and
prime order l. Adding together l copies of the same element gives the
identity. Adding the identity element to
any element returns that element unchanged. Negation returns an element
that added to the negation input returns the identity element.
Subtraction is the addition of a negated element, and scalar
multiplication is the repeated addition of an element.</t>
</section>
<section anchor="ristretto255"><name>ristretto255</name>
<t>ristretto255 is an instantiation of the abstract prime-order group
interface defined in <xref target="interface"></xref>. This document describes how to
implement the ristretto255 prime-order group using Curve25519 points as
internal representations.</t>
<t>A "ristretto255 group element" is the abstract element of the prime
order group. An "element encoding" is the unique reversible encoding
of a group element. An "internal representation" is a point on the
curve used to implement ristretto255. Each group element can have
multiple equivalent internal representations.</t>
<t>Encoding, decoding, equality, and the element derivation function are defined in
<xref target="functions255"></xref>. Element addition, subtraction, negation, and scalar
multiplication are implemented by applying the corresponding operations
directly to the internal representation.</t>
<t>The group order is the same as the order of the Curve25519 prime-order subgroup:</t>
<artwork><![CDATA[l = 2^252 + 27742317777372353535851937790883648493
]]>
</artwork>
<t>Since ristretto255 is a prime-order group, every element except the
identity is a generator, but for interoperability a canonical generator
is selected, which can be internally represented by the Curve25519
basepoint, enabling reuse of existing precomputation for scalar
multiplication. This is its encoding as produced by the function
specified in <xref target="encoding255"></xref>:</t>
<artwork><![CDATA[e2f2ae0a 6abc4e71 a884a961 c500515f 58e30b6a a582dd8d b6a65945 e08d2d76
]]>
</artwork>
<section anchor="constants255"><name>Implementation constants</name>
<t>This document references the following constant field element values
that are used for the implementation of group operations.</t>
<ul spacing="compact">
<li><t><tt>D</tt> = 37095705934669439343138083508754565189542113879843219016388785533085940283555</t>
<ul spacing="compact">
<li>This is the Edwards d parameter for Curve25519, as specified in Section 4.1 of <xref target="RFC7748"></xref>.</li>
</ul></li>
<li><tt>SQRT_M1</tt> = 19681161376707505956807079304988542015446066515923890162744021073123829784752</li>
<li><tt>SQRT_AD_MINUS_ONE</tt> = 25063068953384623474111414158702152701244531502492656460079210482610430750235</li>
<li><tt>INVSQRT_A_MINUS_D</tt> = 54469307008909316920995813868745141605393597292927456921205312896311721017578</li>
<li><tt>ONE_MINUS_D_SQ</tt> = 1159843021668779879193775521855586647937357759715417654439879720876111806838</li>
<li><tt>D_MINUS_ONE_SQ</tt> = 40440834346308536858101042469323190826248399146238708352240133220865137265952</li>
</ul>
</section>
<section anchor="sqrtratio255"><name>Square root of a ratio of field elements</name>
<t>The following function is defined on field elements, and is used to
implement other ristretto255 functions. This function is only used internally
to implement some of the group operations.</t>
<t>On input field elements u and v, the function <tt>SQRT_RATIO_M1(u, v)</tt> returns:</t>
<ul spacing="compact">
<li><tt>(TRUE, +sqrt(u/v))</tt> if u and v are non-zero, and u/v is square;</li>
<li><tt>(TRUE, zero)</tt> if u is zero;</li>
<li><tt>(FALSE, zero)</tt> if v is zero and u is non-zero;</li>
<li><tt>(FALSE, +sqrt(SQRT_M1*(u/v)))</tt> if u and v are non-zero, and u/v is
non-square (so <tt>SQRT_M1*(u/v)</tt> is square),</li>
</ul>
<t>where <tt>+sqrt(x)</tt> indicates the non-negative square root of x in the
field.</t>
<t>The computation is similar to Section 5.1.3 of <xref target="RFC8032"></xref>, with the
difference that if the input is non-square, the function returns a
result with a defined relationship to the inputs. This result is used
for efficient implementation of the derivation function. The function
can be refactored from an existing Ed25519 implementation.</t>
<t><tt>SQRT_RATIO_M1(u, v)</tt> is defined as follows:</t>
<artwork><![CDATA[r = (u * v^3) * (u * v^7)^((p-5)/8) // Note: (p - 5) / 8 is an integer.
check = v * r^2
correct_sign_sqrt = CT_EQ(check, u)
flipped_sign_sqrt = CT_EQ(check, -u)
flipped_sign_sqrt_i = CT_EQ(check, -u*SQRT_M1)
r_prime = SQRT_M1 * r
r = CT_SELECT(r_prime IF flipped_sign_sqrt | flipped_sign_sqrt_i ELSE r)
// Choose the nonnegative square root.
r = CT_ABS(r)
was_square = correct_sign_sqrt | flipped_sign_sqrt
return (was_square, r)
]]>
</artwork>
</section>
<section anchor="functions255"><name>ristretto255 group operations</name>
<t>This section describes the implementation of the external functions
exposed by the ristretto255 prime-order group.</t>
<section anchor="decoding255"><name>Decode</name>
<t>All elements are encoded as 32-byte strings. Decoding proceeds as follows:</t>
<ol spacing="compact">
<li><t>First, interpret the string as an unsigned integer s in little-endian
representation. If the length of the string is not 32 bytes, or if
the resulting value is >= p, decoding fails.</t>
<ul spacing="compact">
<li>Note: unlike <xref target="RFC7748"></xref> field element decoding, the most significant
bit is not masked, and non-canonical values are rejected.
The test vectors in <xref target="invalid255"></xref> exercise these edge cases.</li>
</ul></li>
<li>If <tt>IS_NEGATIVE(s)</tt> returns TRUE, decoding fails.</li>
<li>Process s as follows:</li>
</ol>
<artwork><![CDATA[ss = s^2
u1 = 1 - ss
u2 = 1 + ss
u2_sqr = u2^2
v = -(D * u1^2) - u2_sqr
(was_square, invsqrt) = SQRT_RATIO_M1(1, v * u2_sqr)
den_x = invsqrt * u2
den_y = invsqrt * den_x * v
x = CT_ABS(2 * s * den_x)
y = u1 * den_y
t = x * y
]]>
</artwork>
<ol spacing="compact" start="4">
<li>If was_square is FALSE, or <tt>IS_NEGATIVE(t)</tt> returns TRUE, or y =
0, decoding fails. Otherwise, return the group element represented
by the internal representation <tt>(x, y, 1, t)</tt> as the result of
decoding.</li>
</ol>
</section>
<section anchor="encoding255"><name>Encode</name>
<t>A group element with internal representation <tt>(x0, y0, z0, t0)</tt> is
encoded as follows:</t>
<ol spacing="compact">
<li>Process the internal representation into a field element s as follows:</li>
</ol>
<artwork><![CDATA[u1 = (z0 + y0) * (z0 - y0)
u2 = x0 * y0
// Ignore was_square since this is always square.
(_, invsqrt) = SQRT_RATIO_M1(1, u1 * u2^2)
den1 = invsqrt * u1
den2 = invsqrt * u2
z_inv = den1 * den2 * t0
ix0 = x0 * SQRT_M1
iy0 = y0 * SQRT_M1
enchanted_denominator = den1 * INVSQRT_A_MINUS_D
rotate = IS_NEGATIVE(t0 * z_inv)
// Conditionally rotate x and y.
x = CT_SELECT(iy0 IF rotate ELSE x0)
y = CT_SELECT(ix0 IF rotate ELSE y0)
z = z0
den_inv = CT_SELECT(enchanted_denominator IF rotate ELSE den2)
y = CT_SELECT(-y IF IS_NEGATIVE(x * z_inv) ELSE y)
s = CT_ABS(den_inv * (z - y))
]]>
</artwork>
<ol spacing="compact" start="2">
<li>Return the 32-byte little-endian encoding of s. More specifically,
this is the encoding of the canonical representation of s as an integer
between 0 and p-1, inclusive.</li>
</ol>
<t>Note that decoding and then re-encoding a valid group element will
yield an identical byte string.</t>
</section>
<section anchor="equals255"><name>Equals</name>
<t>The equality function returns TRUE when two internal representations
correspond to the same group element. Note that internal representations
<bcp14>MUST NOT</bcp14> be compared in any other way than specified here.</t>
<t>For two internal representations <tt>(x1, y1, z1, t1)</tt> and <tt>(x2, y2, z2, t2)</tt>,
if</t>
<artwork><![CDATA[(x1 * y2 == y1 * x2) | (y1 * y2 == x1 * x2)
]]>
</artwork>
<t>evaluates to TRUE, then return TRUE. Otherwise, return FALSE.</t>
<t>Note that the equality function always returns TRUE when applied to an
internal representation and to the internal representation obtained by
encoding and then re-decoding it. However, the internal
representations themselves might not be identical.</t>
<t>Implementations <bcp14>MAY</bcp14> also perform byte comparisons on the encodings
of group elements (produced by <xref target="encoding255"></xref>) for an equivalent, although
less efficient, result.</t>
</section>
<section anchor="from_bytes_uniform255"><name>Element derivation</name>
<t>The element derivation function operates on 64-byte strings.
To obtain such an input from an arbitrary-length byte string, applications
should use a domain-separated hash construction, the choice of which
is out-of-scope for this document.</t>
<t>The element derivation function on an input string b proceeds as follows:</t>
<ol spacing="compact">
<li>Compute P1 as <tt>MAP(b[0:32])</tt>.</li>
<li>Compute P2 as <tt>MAP(b[32:64])</tt>.</li>
<li>Return P1 + P2.</li>
</ol>
<t>The MAP function is defined on 32-byte strings as:</t>
<ol>
<li><t>First, mask the most significant bit in the final byte of the string,
and interpret the string as an unsigned integer r in little-endian
representation. Reduce r modulo p to obtain a field element t.</t>
<ul spacing="compact">
<li>Masking the most significant bit is equivalent to interpreting the
whole string as an unsigned integer in little-endian representation and then
reducing it modulo 2^255.</li>
<li>Note: similarly to <xref target="RFC7748"></xref> field element decoding, and unlike
field element decoding in <xref target="decoding255"></xref>, the most significant bit
is masked, and non-canonical values are accepted.</li>
</ul></li>
<li><t>Process t as follows:</t>
</li>
</ol>
<artwork><![CDATA[r = SQRT_M1 * t^2
u = (r + 1) * ONE_MINUS_D_SQ
v = (-1 - r*D) * (r + D)
(was_square, s) = SQRT_RATIO_M1(u, v)
s_prime = -CT_ABS(s*t)
s = CT_SELECT(s IF was_square ELSE s_prime)
c = CT_SELECT(-1 IF was_square ELSE r)
N = c * (r - 1) * D_MINUS_ONE_SQ - v
w0 = 2 * s * v
w1 = N * SQRT_AD_MINUS_ONE
w2 = 1 - s^2
w3 = 1 + s^2
]]>
</artwork>
<ol spacing="compact" start="3">
<li>Return the group element represented by the internal representation
<tt>(w0*w3, w2*w1, w1*w3, w0*w2)</tt>.</li>
</ol>
</section>
</section>
<section anchor="scalar-field"><name>Scalar field</name>
<t>The scalars for the ristretto255 group are integers modulo the order l
of the ristretto255 group. Note that this is the same scalar field as
Curve25519, allowing existing implementations to be reused.</t>
<t>Scalars are encoded as 32-byte strings in little-endian order.
Implementations <bcp14>SHOULD</bcp14> check that any scalar s falls in the range
0 <= s < l when parsing them and reject non-canonical scalar
encodings. Implementations <bcp14>SHOULD</bcp14> reduce scalars modulo l when
encoding them as byte strings. Omitting these strict range checks is
<bcp14>NOT RECOMMENDED</bcp14> but is allowed to enable reuse of scalar
arithmetic implementations in existing Curve25519 libraries.</t>
<t>Given a uniformly distributed 64-byte string b, implementations can
obtain a uniformly distributed scalar by interpreting the 64-byte
string as a 512-bit unsigned integer in little-endian order and reducing the
integer modulo l, as in <xref target="RFC8032"></xref>. To obtain such an input from an
arbitrary-length byte string, applications should use a domain-separated
hash construction, the choice of which is out-of-scope for this document.</t>
</section>
</section>
<section anchor="decaf448"><name>decaf448</name>
<t>decaf448 is an instantiation of the abstract prime-order group
interface defined in <xref target="interface"></xref>. This document describes how to
implement the decaf448 prime-order group using edwards448 points as
internal representations.</t>
<t>A "decaf448 group element" is the abstract element of the prime order
group. An "element encoding" is the unique reversible encoding of a
group element. An "internal representation" is a point on the curve
used to implement decaf448. Each group element can have multiple
equivalent internal representations.</t>
<t>Encoding, decoding, equality, and the element derivation functions are defined in
<xref target="functions448"></xref>. Element addition, subtraction, negation, and scalar
multiplication are implemented by applying the corresponding operations
directly to the internal representation.</t>
<t>The group order is the same as the order of the edwards448 prime-order subgroup:</t>
<artwork><![CDATA[l = 2^446 -
13818066809895115352007386748515426880336692474882178609894547503885
]]>
</artwork>
<t>Since decaf448 is a prime-order group, every element except the
identity is a generator, but for interoperability a canonical generator
is selected. This generator can be internally represented by 2*<tt>B</tt>, where <tt>B</tt> is the edwards448
basepoint, enabling reuse of existing precomputation for scalar
multiplication. This is its encoding as produced by the function
specified in <xref target="encoding448"></xref>:</t>
<artwork><![CDATA[66666666 66666666 66666666 66666666 66666666 66666666 66666666
33333333 33333333 33333333 33333333 33333333 33333333 33333333
]]>
</artwork>
<t>This repetitive constant is equal to <tt>1/sqrt(5)</tt> in decaf448's field,
corresponding to the curve448 base point with x = 5.</t>
<section anchor="constants448"><name>Implementation constants</name>
<t>This document references the following constant field element values
that are used for the implementation of group operations.</t>
<ul spacing="compact">
<li><t><tt>D</tt> = 726838724295606890549323807888004534353641360687318060281490199180612328166730772686396383698676545930088884461843637361053498018326358</t>
<ul spacing="compact">
<li>This is the Edwards d parameter for edwards448, as specified in
Section 4.2 of <xref target="RFC7748"></xref>, and is equal to -39081 in the field.</li>
</ul></li>
<li><tt>ONE_MINUS_D</tt> = 39082</li>
<li><tt>ONE_MINUS_TWO_D</tt> = 78163</li>
<li><tt>SQRT_MINUS_D</tt> = 98944233647732219769177004876929019128417576295529901074099889598043702116001257856802131563896515373927712232092845883226922417596214</li>
<li><tt>INVSQRT_MINUS_D</tt> = 315019913931389607337177038330951043522456072897266928557328499619017160722351061360252776265186336876723201881398623946864393857820716</li>
</ul>
</section>
<section anchor="sqrtratio448"><name>Square root of a ratio of field elements</name>
<t>The following function is defined on field elements, and is used to
implement other decaf448 functions. This function is only used internally
to implement some of the group operations.</t>
<t>On input field elements u and v, the function <tt>SQRT_RATIO_M1(u, v)</tt> returns:</t>
<ul spacing="compact">
<li><tt>(TRUE, +sqrt(u/v))</tt> if u and v are non-zero, and u/v is square;</li>
<li><tt>(TRUE, zero)</tt> if u is zero;</li>
<li><tt>(FALSE, zero)</tt> if v is zero and u is non-zero;</li>
<li><tt>(FALSE, +sqrt(-u/v))</tt> if u and v are non-zero, and u/v is
non-square (so <tt>-(u/v)</tt> is square),</li>
</ul>
<t>where <tt>+sqrt(x)</tt> indicates the non-negative square root of x in
the field.</t>
<t>The computation is similar to Section 5.2.3 of <xref target="RFC8032"></xref>, with the
difference that if the input is non-square, the function returns a
result with a defined relationship to the inputs. This result is used
for efficient implementation of the derivation function. The function
can be refactored from an existing edwards448 implementation.</t>
<t><tt>SQRT_RATIO_M1(u, v)</tt> is defined as follows:</t>
<artwork><![CDATA[r = u * (u * v)^((p - 3) / 4) // Note: (p - 3) / 4 is an integer.
check = v * r^2
was_square = CT_EQ(check, u)
// Choose the nonnegative square root.
r = CT_ABS(r)
return (was_square, r)
]]>
</artwork>
</section>
<section anchor="functions448"><name>decaf448 group operations</name>
<t>This section describes the implementation of the external functions
exposed by the decaf448 prime-order group.</t>
<section anchor="decoding448"><name>Decode</name>
<t>All elements are encoded as 56-byte strings. Decoding proceeds as follows:</t>
<ol spacing="compact">
<li><t>First, interpret the string as an unsigned integer s in little-endian
representation. If the length of the string is not 56 bytes, or if
the resulting value is >= p, decoding fails.</t>
<ul spacing="compact">
<li>Note: unlike <xref target="RFC7748"></xref> field element decoding, non-canonical
values are rejected. The test vectors in <xref target="invalid448"></xref> exercise
these edge cases.</li>
</ul></li>
<li>If <tt>IS_NEGATIVE(s)</tt> returns TRUE, decoding fails.</li>
<li>Process s as follows:</li>
</ol>
<artwork><![CDATA[ss = s^2
u1 = 1 + ss
u2 = u1^2 - 4 * D * ss
(was_square, invsqrt) = SQRT_RATIO_M1(1, u2 * u1^2)
u3 = CT_ABS(2 * s * invsqrt * u1 * SQRT_MINUS_D)
x = u3 * invsqrt * u2 * INVSQRT_MINUS_D
y = (1 - ss) * invsqrt * u1
t = x * y
]]>
</artwork>
<ol spacing="compact" start="4">
<li>If was_square is FALSE then decoding fails. Otherwise,
return the group element represented by the internal representation
<tt>(x, y, 1, t)</tt> as the result of decoding.</li>
</ol>
</section>
<section anchor="encoding448"><name>Encode</name>
<t>A group element with internal representation <tt>(x0, y0, z0, t0)</tt> is
encoded as follows:</t>
<ol spacing="compact">
<li>Process the internal representation into a field element s as follows:</li>
</ol>
<artwork><![CDATA[u1 = (x0 + t0) * (x0 - t0)
// Ignore was_square since this is always square.
(_, invsqrt) = SQRT_RATIO_M1(1, u1 * ONE_MINUS_D * x0^2)
ratio = CT_ABS(invsqrt * u1 * SQRT_MINUS_D)
u2 = INVSQRT_MINUS_D * ratio * z0 - t0
s = CT_ABS(ONE_MINUS_D * invsqrt * x0 * u2)
]]>
</artwork>
<ol spacing="compact" start="2">
<li>Return the 56-byte little-endian encoding of s. More specifically,
this is the encoding of the canonical representation of s as an integer
between 0 and p-1, inclusive.</li>
</ol>
<t>Note that decoding and then re-encoding a valid group element will
yield an identical byte string.</t>
</section>
<section anchor="equals448"><name>Equals</name>
<t>The equality function returns TRUE when two internal representations
correspond to the same group element. Note that internal representations
<bcp14>MUST NOT</bcp14> be compared in any other way than specified here.</t>
<t>For two internal representations <tt>(x1, y1, z1, t1)</tt> and <tt>(x2, y2, z2, t2)</tt>,
if</t>
<artwork><![CDATA[x1 * y2 == y1 * x2
]]>
</artwork>
<t>evaluates to TRUE, then return TRUE. Otherwise, return FALSE.</t>
<t>Note that the equality function always returns TRUE when applied to an
internal representation and to the internal representation obtained by
encoding and then re-decoding it. However, the internal
representations themselves might not be identical.</t>
<t>Implementations <bcp14>MAY</bcp14> also perform byte comparisons on the encodings
of group elements (produced by <xref target="encoding448"></xref>) for an equivalent, although
less efficient, result.</t>
</section>
<section anchor="from_bytes_uniform448"><name>Element derivation</name>
<t>The element derivation function operates on 112-byte strings.
To obtain such an input from an arbitrary-length byte string, applications
should use a domain-separated hash construction, the choice of which
is out-of-scope for this document.</t>
<t>The element derivation function on an input string b proceeds as follows:</t>
<ol spacing="compact">
<li>Compute P1 as <tt>MAP(b[0:56])</tt>.</li>
<li>Compute P2 as <tt>MAP(b[56:112])</tt>.</li>
<li>Return P1 + P2.</li>
</ol>
<t>The MAP function is defined on 56-byte strings as:</t>
<ol>
<li><t>Interpret the string as an unsigned integer r in little-endian representation.
Reduce r modulo p to obtain a field element t.</t>
<ul spacing="compact">
<li>Note: similarly to <xref target="RFC7748"></xref> field element decoding, and unlike
field element decoding in <xref target="decoding448"></xref>, non-canonical values are
accepted.</li>
</ul></li>
<li><t>Process t as follows:</t>
</li>
</ol>
<artwork><![CDATA[r = -t^2
u0 = d * (r-1)
u1 = (u0 + 1) * (u0 - r)
(was_square, v) = SQRT_RATIO_M1(ONE_MINUS_TWO_D, (r + 1) * u1)
v_prime = CT_SELECT(v IF was_square ELSE t * v)
sgn = CT_SELECT(1 IF was_square ELSE -1)
s = v_prime * (r + 1)
w0 = 2 * CT_ABS(s)
w1 = s^2 + 1
w2 = s^2 - 1
w3 = v_prime * s * (r - 1) * ONE_MINUS_TWO_D + sgn
]]>
</artwork>
<ol spacing="compact" start="3">
<li>Return the group element represented by the internal representation
<tt>(w0*w3, w2*w1, w1*w3, w0*w2)</tt>.</li>
</ol>
</section>
</section>
<section anchor="scalar-field-1"><name>Scalar field</name>
<t>The scalars for the decaf448 group are integers modulo the order l
of the decaf448 group. Note that this is the same scalar field as
edwards448, allowing existing implementations to be reused.</t>
<t>Scalars are encoded as 56-byte strings in little-endian order.
Implementations <bcp14>SHOULD</bcp14> check that any scalar s falls in the range
0 <= s < l when parsing them and reject non-canonical scalar
encodings. Implementations <bcp14>SHOULD</bcp14> reduce scalars modulo l when
encoding them as byte strings. Omitting these strict range checks is
<bcp14>NOT RECOMMENDED</bcp14> but is allowed to enable reuse of scalar
arithmetic implementations in existing edwards448 libraries.</t>
<t>Given a uniformly distributed 64-byte string b, implementations can
obtain a uniformly distributed scalar by interpreting the 64-byte
string as a 512-bit unsigned integer in little-endian order and reducing the
integer modulo l. To obtain such an input from an arbitrary-length
byte string, applications should use a domain-separated hash
construction, the choice of which is out-of-scope for this document.</t>
</section>
</section>
<section anchor="api"><name>API Considerations</name>
<t>ristretto255 and decaf448 are abstractions which implement two prime-order
groups, and their elements are represented by curve points, but they are
not curve points. Implementations <bcp14>SHOULD</bcp14> reflect that: the type
representing an element of the group <bcp14>SHOULD</bcp14> be opaque to the caller,
meaning they do not expose the underlying curve point or field elements.
Moreover, implementations <bcp14>SHOULD NOT</bcp14> expose any internal constants
or functions used in the implementation of the group operations.</t>
<t>The reason for this encapsulation is that ristretto255 and decaf448 implementations
can change their underlying curve without causing any breaking change. The ristretto255
and decaf448 constructions are carefully designed so that this will be the
case, as long as implementations do not expose internal representations or
operate on them except as described in this document. In particular,
implementations <bcp14>SHOULD NOT</bcp14> define any external ristretto255 or decaf448
interface as operating on arbitrary curve points, and they <bcp14>SHOULD NOT</bcp14>
construct group elements except via decoding, the element derivation function,
or group operations on other valid group elements per <xref target="interface"></xref>. They are
however allowed to apply any optimization strategy to the internal
representations as long as it doesn't change the exposed behavior of the
API.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that implementations do not perform a decoding and
encoding operation for each group operation, as it is inefficient and
unnecessary. Implementations <bcp14>SHOULD</bcp14> instead provide an opaque type
to hold the internal representation through multiple operations.</t>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>The ristretto255 and decaf448 groups provide higher-level protocols with
the abstraction they expect: a prime-order group. Therefore, it's expected
to be safer for use in any situation where Curve25519 or edwards448 is used
to implement a protocol requiring a prime-order group. Note that the safety
of the abstraction can be defeated by implementations that do not follow
the guidance in <xref target="api"></xref>.</t>
<t>There is no function to test whether an elliptic curve point is a
valid internal representation of a group element. The decoding
function always returns a valid internal representation, or an error, and
allowed operations on valid internal representations return valid
internal representations. In this way, an implementation can maintain
the invariant that an internal representation is always valid, so that
checking is never necessary, and invalid states are unrepresentable.</t>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>The authors would like to thank Daira Hopwood, Riad S. Wahby, Christopher Wood,
and Thomas Pornin for their comments on the draft.</t>
</section>
</middle>
<back>
<references><name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="Decaf" target="https://www.shiftleft.org/papers/decaf/decaf.pdf">
<front>
<title>Decaf: Eliminating cofactors through point
compression</title>
<author fullname="Mike Hamburg" initials="M." surname="Hamburg">
<organization>Rambus Cryptography Research</organization>
</author>
<date year="2015"></date>
</front>
</reference>
<reference anchor="MoneroVuln" target="https://jonasnick.github.io/blog/2017/05/23/exploiting-low-order-generators-in-one-time-ring-signatures/">
<front>
<title>Exploiting Low Order Generators in One-Time Ring Signatures</title>
<author fullname="Jonas Nick" initials="J." surname="Nick"></author>
<date year="2017"></date>
</front>
</reference>
<reference anchor="Naming" target="https://mailarchive.ietf.org/arch/msg/cfrg/-9LEdnzVrE5RORux3Oo_oDDRksU/">
<front>
<title>[Cfrg] 25519 naming</title>
<author fullname="Daniel J. Bernstein" initials="D. J." surname="Bernstein"></author>
<date year="2014"></date>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
<reference anchor="RistrettoGroup" target="https://ristretto.group">
<front>
<title>The Ristretto Group</title>
<author fullname="Henry de Valence" initials="H" surname="de Valence"></author>
<author fullname="isis lovecruft" initials="I" surname="Lovecruft"></author>
<author fullname="Tony Arcieri" initials="T" surname="Arcieri"></author>
<author fullname="Mike Hamburg" initials="M" surname="Hamburg"></author>
<date year="2018"></date>
</front>
</reference>
<reference anchor="Twisted" target="https://eprint.iacr.org/2008/522">
<front>
<title>Twisted Edwards Curves Revisited</title>
<author fullname="Huseyin Hisil" initials="H." surname="Hisil"></author>
<author fullname="Kenneth Koon-Ho Wong" initials="K. K." surname="Wong"></author>
<author fullname="Gary Carter" initials="G." surname="Carter"></author>
<author fullname="Ed Dawson" initials="E." surname="Dawson"></author>
<date year="2008"></date>
</front>
</reference>
<reference anchor="draft-irtf-cfrg-hash-to-curve-16" target="https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/">
<front>
<title>Hashing to Elliptic Curves</title>
<author fullname="Armando Faz-Hernández" initials="A." surname="Faz-Hernández"></author>
<author fullname="Sam Scott" initials="S." surname="Scott"></author>
<author fullname="Nick Sullivan" initials="N." surname="Sullivan"></author>
<author fullname="Riad S. Wahby" initials="R.S." surname="Wahby"></author>
<author fullname="Christopher A. Wood" initials="C.A." surname="Wood"></author>
<date year="2022"></date>
</front>
</reference>
</references>
<section anchor="test-vectors-for-ristretto255"><name>Test vectors for ristretto255</name>
<t>This section contains test vectors for ristretto255. The octets are
hex encoded, and whitespace is inserted for readability.</t>
<section anchor="multiples-of-the-generator"><name>Multiples of the generator</name>
<t>The following are the encodings of the multiples 0 to 15 of the
canonical generator, represented as an array of elements. That is,
the first entry is the encoding of the identity element, and each
successive entry is obtained by adding the generator to the previous entry.</t>
<artwork><![CDATA[B[ 0]: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
B[ 1]: e2f2ae0a 6abc4e71 a884a961 c500515f 58e30b6a a582dd8d b6a65945 e08d2d76
B[ 2]: 6a493210 f7499cd1 7fecb510 ae0cea23 a110e8d5 b901f8ac add3095c 73a3b919
B[ 3]: 94741f5d 5d52755e ce4f23f0 44ee27d5 d1ea1e2b d196b462 166b1615 2a9d0259
B[ 4]: da808627 73358b46 6ffadfe0 b3293ab3 d9fd53c5 ea6c9553 58f56832 2daf6a57
B[ 5]: e882b131 016b52c1 d3337080 187cf768 423efccb b517bb49 5ab812c4 160ff44e
B[ 6]: f64746d3 c92b1305 0ed8d802 36a7f000 7c3b3f96 2f5ba793 d19a601e bb1df403
B[ 7]: 44f53520 926ec81f bd5a3878 45beb7df 85a96a24 ece18738 bdcfa6a7 822a176d
B[ 8]: 903293d8 f2287ebe 10e2374d c1a53e0b c887e592 699f02d0 77d5263c dd55601c
B[ 9]: 02622ace 8f7303a3 1cafc63f 8fc48fdc 16e1c8c8 d234b2f0 d6685282 a9076031
B[10]: 20706fd7 88b2720a 1ed2a5da d4952b01 f413bcf0 e7564de8 cdc81668 9e2db95f
B[11]: bce83f8b a5dd2fa5 72864c24 ba1810f9 522bc600 4afe9587 7ac73241 cafdab42
B[12]: e4549ee1 6b9aa030 99ca208c 67adafca fa4c3f3e 4e5303de 6026e3ca 8ff84460
B[13]: aa52e000 df2e16f5 5fb1032f c33bc427 42dad6bd 5a8fc0be 0167436c 5948501f
B[14]: 46376b80 f409b29d c2b5f6f0 c5259199 0896e571 6f41477c d30085ab 7f10301e
B[15]: e0c418f7 c8d9c4cd d7395b93 ea124f3a d99021bb 681dfc33 02a9d99a 2e53e64e
]]>
</artwork>
<t>Note that because</t>
<artwork><![CDATA[B[i+1] = B[i] + B[1]
]]>
</artwork>
<t>these test vectors allow testing the encoding function and
the implementation of addition simultaneously.</t>
</section>
<section anchor="invalid255"><name>Invalid encodings</name>
<t>These are examples of encodings that <bcp14>MUST</bcp14> be rejected according to
<xref target="decoding255"></xref>.</t>
<artwork><![CDATA[# Non-canonical field encodings.
00ffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff7f
f3ffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff7f
edffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff7f
# Negative field elements.
01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
01ffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff7f
ed57ffd8 c914fb20 1471d1c3 d245ce3c 746fcbe6 3a3679d5 1b6a516e bebe0e20
c34c4e18 26e5d403 b78e246e 88aa051c 36ccf0aa febffe13 7d148a2b f9104562
c940e5a4 404157cf b1628b10 8db051a8 d439e1a4 21394ec4 ebccb9ec 92a8ac78
47cfc549 7c53dc8e 61c91d17 fd626ffb 1c49e2bc a94eed05 2281b510 b1117a24
f1c6165d 33367351 b0da8f6e 4511010c 68174a03 b6581212 c71c0e1d 026c3c72
87260f7a 2f124951 18360f02 c26a470f 450dadf3 4a413d21 042b43b9 d93e1309
# Non-square x^2.
26948d35 ca62e643 e26a8317 7332e6b6 afeb9d08 e4268b65 0f1f5bbd 8d81d371
4eac077a 713c57b4 f4397629 a4145982 c661f480 44dd3f96 427d40b1 47d9742f
de6a7b00 deadc788 eb6b6c8d 20c0ae96 c2f20190 78fa604f ee5b87d6 e989ad7b
bcab477b e20861e0 1e4a0e29 5284146a 510150d9 817763ca f1a6f4b4 22d67042
2a292df7 e32cabab bd9de088 d1d1abec 9fc0440f 637ed2fb a145094d c14bea08
f4a9e534 fc0d216c 44b218fa 0c42d996 35a0127e e2e53c71 2f706096 49fdff22
8268436f 8c412619 6cf64b3c 7ddbda90 746a3786 25f9813d d9b84570 77256731
2810e5cb c2cc4d4e ece54f61 c6f69758 e289aa7a b440b3cb eaa21995 c2f4232b
# Negative xy value.
3eb858e7 8f5a7254 d8c97311 74a94f76 755fd394 1c0ac937 35c07ba1 4579630e
a45fdc55 c76448c0 49a1ab33 f17023ed fb2be358 1e9c7aad e8a61252 15e04220
d483fe81 3c6ba647 ebbfd3ec 41adca1c 6130c2be eee9d9bf 065c8d15 1c5f396e
8a2e1d30 050198c6 5a544831 23960ccc 38aef684 8e1ec8f5 f780e852 3769ba32
32888462 f8b486c6 8ad7dd96 10be5192 bbeaf3b4 43951ac1 a8118419 d9fa097b
22714250 1b9d4355 ccba2904 04bde415 75b03769 3cef1f43 8c47f8fb f35d1165
5c37cc49 1da847cf eb9281d4 07efc41e 15144c87 6e0170b4 99a96a22 ed31e01e
44542511 7cb8c90e dcbc7c1c c0e74f74 7f2c1efa 5630a967 c64f2877 92a48a4b
# s = -1, which causes y = 0.
ecffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff7f
]]>
</artwork>
</section>
<section anchor="group-elements-from-byte-strings"><name>Group elements from byte strings</name>
<t>The following pairs are inputs to the element derivation function of
<xref target="from_bytes_uniform255"></xref>, and their encoded outputs.</t>
<artwork><![CDATA[I: 5d1be09e3d0c82fc538112490e35701979d99e06ca3e2b5b54bffe8b4dc772c1
4d98b696a1bbfb5ca32c436cc61c16563790306c79eaca7705668b47dffe5bb6
O: 3066f82a 1a747d45 120d1740 f1435853 1a8f04bb ffe6a819 f86dfe50 f44a0a46
I: f116b34b8f17ceb56e8732a60d913dd10cce47a6d53bee9204be8b44f6678b27
0102a56902e2488c46120e9276cfe54638286b9e4b3cdb470b542d46c2068d38
O: f26e5b6f 7d362d2d 2a94c5d0 e7602cb4 773c95a2 e5c31a64 f133189f a76ed61b
I: 8422e1bbdaab52938b81fd602effb6f89110e1e57208ad12d9ad767e2e25510c
27140775f9337088b982d83d7fcf0b2fa1edffe51952cbe7365e95c86eaf325c
O: 006ccd2a 9e6867e6 a2c5cea8 3d3302cc 9de128dd 2a9a57dd 8ee7b9d7 ffe02826
I: ac22415129b61427bf464e17baee8db65940c233b98afce8d17c57beeb7876c2
150d15af1cb1fb824bbd14955f2b57d08d388aab431a391cfc33d5bafb5dbbaf
O: f8f0c87c f237953c 5890aec3 99816900 5dae3eca 1fbb0454 8c635953 c817f92a
I: 165d697a1ef3d5cf3c38565beefcf88c0f282b8e7dbd28544c483432f1cec767
5debea8ebb4e5fe7d6f6e5db15f15587ac4d4d4a1de7191e0c1ca6664abcc413
O: ae81e7de df20a497 e10c304a 765c1767 a42d6e06 029758d2 d7e8ef7c c4c41179
I: a836e6c9a9ca9f1e8d486273ad56a78c70cf18f0ce10abb1c7172ddd605d7fd2
979854f47ae1ccf204a33102095b4200e5befc0465accc263175485f0e17ea5c
O: e2705652 ff9f5e44 d3e841bf 1c251cf7 dddb77d1 40870d1a b2ed64f1 a9ce8628
I: 2cdc11eaeb95daf01189417cdddbf95952993aa9cb9c640eb5058d09702c7462
2c9965a697a3b345ec24ee56335b556e677b30e6f90ac77d781064f866a3c982
O: 80bd0726 2511cdde 4863f8a7 434cef69 6750681c b9510eea 557088f7 6d9e5065
]]>
</artwork>
<t>The following element derivation function inputs all produce the same encoded
output.</t>
<artwork><![CDATA[I: edffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
1200000000000000000000000000000000000000000000000000000000000000
I: edffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
I: 0000000000000000000000000000000000000000000000000000000000000080
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f
I: 0000000000000000000000000000000000000000000000000000000000000000
1200000000000000000000000000000000000000000000000000000000000080
O: 30428279 1023b731 28d277bd cb5c7746 ef2eac08 dde9f298 3379cb8e 5ef0517f
]]>
</artwork>
</section>
<section anchor="square-root-of-a-ratio-of-field-elements"><name>Square root of a ratio of field elements</name>
<t>The following are inputs and outputs of <tt>SQRT_RATIO_M1(u, v)</tt> defined
in <xref target="sqrtratio255"></xref>. The values are little-endian encodings of field
elements.</t>
<artwork><![CDATA[u: 0000000000000000000000000000000000000000000000000000000000000000
v: 0000000000000000000000000000000000000000000000000000000000000000
was_square: TRUE
r: 0000000000000000000000000000000000000000000000000000000000000000
u: 0000000000000000000000000000000000000000000000000000000000000000
v: 0100000000000000000000000000000000000000000000000000000000000000
was_square: TRUE
r: 0000000000000000000000000000000000000000000000000000000000000000
u: 0100000000000000000000000000000000000000000000000000000000000000
v: 0000000000000000000000000000000000000000000000000000000000000000
was_square: FALSE
r: 0000000000000000000000000000000000000000000000000000000000000000
u: 0200000000000000000000000000000000000000000000000000000000000000
v: 0100000000000000000000000000000000000000000000000000000000000000
was_square: FALSE
r: 3c5ff1b5d8e4113b871bd052f9e7bcd0582804c266ffb2d4f4203eb07fdb7c54
u: 0400000000000000000000000000000000000000000000000000000000000000
v: 0100000000000000000000000000000000000000000000000000000000000000
was_square: TRUE
r: 0200000000000000000000000000000000000000000000000000000000000000
u: 0100000000000000000000000000000000000000000000000000000000000000
v: 0400000000000000000000000000000000000000000000000000000000000000
was_square: TRUE
r: f6ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff3f
]]>
</artwork>
</section>
</section>
<section anchor="test-vectors-for-decaf448"><name>Test vectors for decaf448</name>