-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathimplementations.txt
94 lines (77 loc) · 3.44 KB
/
implementations.txt
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
{
title: Known Implementations
description: list of known Elligator 2 implementations.
}
Known Elligator 2 Implementations
======================================
These are the implementation we know about as of 2022/06.
Please [contact us](mailto:elligator@loup-vaillant.fr) to have your
implementation added to this list.
Complete implementations
------------------------
They provide a complete implementation,
suitable for key exchange.
- __[libdecaf](https://sourceforge.net/projects/ed448goldilocks/)__
Implements a _variant_ of Elligator for
[ristretto255](https://ristretto.group/)
(based on Curve255) and ristretto448 (based on Curve448).
Implementers seeking to implement Elligator for the Ristretto group
may want to follow libdecaf instead.
This would promote compatibility,
avoid fragmentation,
and would be just as safe
(The libdecaf author basically invented Elligator 2).
- __[Monocypher](https://monocypher.org)__
implements Elligator 2 for Curve25519.
It is designed to be [compatible with X25519](key-exchange).
The map uses <var>Z<sub>u</sub></var> = 2,
non-negative field elements are the set
{0, 1, … (<var>p</var>−1)/2},
and the inverse map always generate positive representatives
(and pad the top _two_ most significant bits with random data).
- __[GNUnet](https://gnunet.org)__
implements Elligator 2 for X25519.
It is very close to Monocypher and Kleshni, but
bits are padded and the [special public key derivation](key-exchange)
is implemented.
The functionality is exposed through a RFC9180-style
KEM interface.
Elligator is used to obfuscate transport-level key exchanges
and authentications of GNUnet peers.
Hash-to-Point implementations
-----------------------------
These only implement the direct map
(without necessarily exposing it),
so random numbers can be mapped to curve points whose discrete logarithm
is unknown
(this is most useful for [Password Authenticated Key
Agreement](https://en.wikipedia.org/wiki/Password-authenticated_key_agreement)).
- __[libsodium](https://libsodium.org)__
uses the Elligator 2 direct map for Ed25519 and
[ristretto255](https://ristretto.group).
For Ed25519 it follows the Map-to-Curve procedure outlined in the
[Hash to curve RFC draft][RFC].
For ristretto255 it only implements [this mapping][rmap],
which is indistinguishable from a random oracle.
[RFC]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve-16
[rmap]: https://ristretto.group/formulas/elligator.html
- __[Curve25519-Dalek](https://dalek.rs/)__
uses the Elligator 2 direct map for Ed25519 and
[ristretto255](https://ristretto.group).
It uses the same strategies as libsodium.
Incomplete implementations
--------------------------
- __[Kleshni](https://github.com/Kleshni/Elligator-2)__
implements Elligator 2 for Curve25519.
It is very close to Monocypher.
The only difference is that the direct map does not ignore the top two
bits.
Instead all 256 bits are interpreted and reduced modulo <var>p</var>.
However, as of 2022/06:
- The inverse map does not pad the representative at all,
so the top two bits are always zero.
To pad those bits in a way that is compatible with its direct map we
need to randomly negate the representative then randomly add
<var>p</var>.
- The [special public key derivation](key-exchange)
required to use the inverse map safely is missing.