-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing Ristretto448 #16
Comments
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/
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 |
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.The text was updated successfully, but these errors were encountered: