# Known Elligator 2 Implementations

These are the implementation we know about as of 2022/06. Please contact us to have your implementation added to this list.

## Complete implementations

They provide a complete implementation, suitable for key exchange.

**libdecaf**Implements a*variant*of Elligator for ristretto255 (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**implements Elligator 2 for Curve25519. It is designed to be compatible with X25519. The map uses`Z`= 2, non-negative field elements are the set {0, 1, … (_{u}`p`−1)/2}, and the inverse map always generate positive representatives (and pad the top*two*most significant bits with random data).

## 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).

**libsodium**uses the Elligator 2 direct map for Ed25519 and ristretto255. For Ed25519 it follows the Map-to-Curve procedure outlined in the Hash to curve RFC draft. For ristretto255 it only implements this mapping, which is indistinguishable from a random oracle.**Curve25519-Dalek**uses the Elligator 2 direct map for Ed25519 and ristretto255. It uses the same strategies as libsodium.

## Incomplete implementations

**Kleshni**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`p`. 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
`p`. - The special public key derivation required to use the inverse map safely is missing.

- 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