Implementing Ristretto448
Opened this issue · 3 comments
In terms of Data structures DecafPoint and RistrettoPoint are similar and differ mainly with the Compression and Decompression.
For now, I think we can have a little code duplication. Then later on, we can have an AbstractPoint "Point" , that does all of the similar features. For now, I will leave the code duplication in as the separation is helpful.
Not sure this is needed actually, as we could just use the direct isogeny that Decaf supplies. But maybe there is a secret advantage to using Ristretto when the curve is defined as an Edwards curve and not Montgomery?
https://sourceforge.net/p/ed448goldilocks/code/ci/master/tree/
As of v0.9.4, libdecaf uses the "Ristretto" variant of this encoding.
See https://www.ristretto.group for details, once that site is up.
A not-so-secret advantage is compatibility and consistency. But changing is a breaking change unless you support both. Though I don't think that libdecaf offers the decaf variant now.
Good point. It would be great to have everything under Ristretto.
The reference contains three encodings, old decaf(pre-Ristretto), new decaf(post-Ristretto) and Ristretto. I don’t think it would be worth it to implement all of them, as not many protocols seem to need old Decaf interoperability from what I’ve seen.
Will give it more thought as I don’t want to cause more confusion on the difference between Ristretto and Decaf/ when to use one over the other