<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 24, 2021, at 1:50 AM, Trevor Perrin <<a href="mailto:trevp@trevp.net" class="">trevp@trevp.net</a>> wrote:</div><div class=""><div class=""> (a) A malicious Alice can't produce an initial message and two<br class="">passwords which decode this message to two different public values<br class="">A1=g^a1 and A2=g^a2 for which Alice knows a1 and a2; because then she<br class="">could check two passwords against Bob's response.</div></div></blockquote><div><br class=""></div>I suspect that this is hard to prove for the XOR encryption, except maybe in the generic group model. I wouldn’t trust the generic group model with Elligator as the encoding — in fact IIRC SIKE is already using non-ideal properties of an Elligator 2 variant in its point compression algorithm.</div><div><br class=""></div><div><br class=""></div><div>Joe wrote:</div><div><blockquote type="cite" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">It looks like Mike was a co-author of the Elligator 1+2 paper [1], so perhaps he can comment regarding which algorithm seems most relevant.</span></blockquote><br class=""><div>Elligator 2 is fine for key exchange, but note that if Trevor wants to replace points in general EC protocols, then it won’t work: it requires the ability to retry a message with different randomness if the point doesn’t encode. For general protocols, you need an encoding that works for all points on the curve, such as Elligator Squared. However, you can always combine them to make “Elligator 2 Squared”, which works for any curve with a point of order 2. This has a separate proof of indifferentiability [5].</div><div><br class=""></div><div>You could also use the “Elligator 2 with wallpapering” approach from that paper, but it’s not implemented as far as I know and has essentially no advantages over “Elligator 2 squared”.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Elligator Squared [2] was written by Mehdi Tibouchi.</span></blockquote><br class=""><div>This would be the best choice for odd-order curves over large fields.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Binary Elligator Squared [3] is yet another paper, I haven't looked into this one.</span></blockquote><br class=""><div>This is for curves over GF(2^n), which are probably not the best choice unless you have an unusual constraint.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Loup Vaillant has an implementation of Elligator 2 in the "Monocypher" library [4], it's the only maintained implementation I've seen.</span></blockquote><br class=""></div><div>Monocypher is an impressive piece of work. My library, libdecaf [6], also implements Elligator 2 and Elligator 2 squared. Note that they are likely incompatible, because libdecaf targets Elligator2 at the Jacobi quartics used by the Ristretto / Decaf encodings, instead of at the Montgomery or Edwards curves.</div><div><br class=""></div><div>Cheers,</div><div>— Mike</div><div><br class=""></div><div>[5] <a href="https://eprint.iacr.org/2020/1513" class="">https://eprint.iacr.org/2020/1513</a></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">[6] <a href="https://sourceforge.net/projects/ed448goldilocks/" style="caret-color: rgb(255, 255, 255);" class="">https://sourceforge.net/projects/ed448goldilocks/</a></div></body></html>