Double-odd elliptic curves by Thomas Pornin

3 thoughts on “Double-odd elliptic curves by Thomas Pornin”

  1. > The encoding is economical: for n-bit security, group elements are encoded over 2n+1 bits (compared to 2n+3 for Ristretto).

    This is splitting hairs since a few bits up or down on security doesn’t really matter. Who has discarded Curve25519 because after Ristretto it only had 126 bits of security instead of 128?

    > For want of a better name, we call them double-odd elliptic curves.

    Had he not named them double-odd, we would’ve likely just called them Pornin curves for want of a better name. Which I might do anyway.

    I’m not a big fan of the 2^(255)-18651 and 2^(255)-3957 fields; fast modular reduction depends on 2^k – c with c being drastically smaller than k. I’ll need to study this in detail to see if there’s maybe a field in the general range of 2^(255) that yields a curve with better modular reduction properties.

    Not defining the inverse map of hash-to-curve is kind of unfortunate, but I understand why this is has no priority.

    I’d also be glad to escape SHA-3 from signature and key exchange schemes for performance reasons.

    Nonetheless, I *greatly* appreciate the massive amount of detail in Pornin’s papers and I’ll still need to study it more.

  2. Neat. You lose a little performance vs Ristretto / Decaf in most cases, but some of the formulas are simpler, particularly the Montgomery ladder, and you can avoid square roots. (Actually, you can avoid square roots for Decaf too, but only if you’re encoding 2P instead of P.)

    Also in 2014, a bunch of folks (Robert Ransom, Trevor Perrin, Watson Ladd, Andrey Jivsov etc) and I developed some related work on the Curves and CFRG mailing lists. One application is that you should be able to do a w-only ladder on these new double-odd curves with only negligible performance loss. This is nicer than the x-only or w^(2)-only ladders because it gives you a canonical point format.

  3. So is this expected to be better than X25519 or Ed25519 on big chips that have AVX2? Or is this only better on ARM Cortex M0+ ? Or is this just neat?


Leave a Comment