This issue lives under the item: https://gitlab.dusk.network/dusk-org/tech/issues/1

Create a document to show that Doppio meets the safe curve criteria. Listed at https://safecurves.cr.yp.to/

Since the curve that Sean provided in:

Here's an "embedded" curve over ristretto255's scalar field

-x^2 + y^2 = 1 - (86649/86650)x^2y^2

which is Ristretto-ready and birationally equivalent to

y^2 = x^3 + 346598x^2 + x (and it's twist secure)

Any other suggestions?

— Sean Bowe (@ebfull) January 22, 2019

Provides values for the Twisted Edwards form that aren't suitable for a Ristretto protocol implementation we have two options:

• Find an isomorphic twist that allows us to mantain the same orders for the Finite Field and also the Sub group, and at the same time, gives a & d values that are suitable for a Ristretto implementation.

• Choice a diferent curve. This will force us to:

  • Find the new order of the Sub group and refactor the Scalar implementation to work over the new order and implement Decaf or Ristretto depending on the co-factor that the new curve provides.

It seems that @Bounce23 found an isomorphic twist that can do the job. We will update here the discussions.

The standard behavior of the RistrettoPoint works like:

RistrettoPoint --> compression --> CompressedRistretto CompressedRistretto --> decompression --> RistrettoPoint

Obviously, the expected behavior for a point compression followed by a point decompression is to obtain the same exact point in Twisted Edwards Extended Coordinates. We should obtain the same RistrettoPoint we used as input.

Also, with the equality formulas that appear on: https://ristretto.group/formulas/equality.html this statement mentioned above should happen always.

So after making some tests, I verified that:

 #[test]
 fn point_comp_decomp_equivalence() {
        // This should give the RISTRETTO_BASEPOINT. 
        assert!(constants::RISTRETTO_BASEPOINT.compress().decompress().unwrap() ==       constants::RISTRETTO_BASEPOINT);
    }

//This test does not pass and it should.

This happened on: e8066b52 and my ideas are:

• The Basepoint is not the one on it's 4-coset that would be encoded as RistettoPoint.
• The compression/decompression processes are not working as expected.
• The point really pertains to the coset and current equalty does not catch it.

Since the algorithm implemented on #9 was passing the tests, we thought that Phase I was working correctly.

But while working on #14 we realized the function only works for the tested value surprisingly ..

So now it's time to find the bug that it's affecting Phase I of the Kalinski's algorithm.

This issue is under the item: https://gitlab.dusk.network/dusk-org/tech/issues/1.

The goal is to implement: Montgomery inversion - Erkay Sava ̧s & Çetin Kaya Koç J Cryptogr Eng (2018) 8:201–210 https://doi.org/10.1007/s13389-017-0161-x

And benchmark the algo vs. Kalinski's one implemented on #9 .

Addition chais are probably a higher performance solution. Maybe @Bounce23 can bring some light researching a bit.

This PR aims to implement:

• RistrettoPoint definition as a wrapper over EdwardsPoint.
• RistrettoPoint ops support (as fast as EdwardsPoint ops are).
• RistrettoPoint Equality testing improvements to the EdwardsPoint one.
• Elligator-ristretto-flavour support for RistrettoPoints.
• Uniformly distributed random point generation.
• ValidityCheck trait for debug purposes.
• 4-coset representation functions.

This issue lives under the item: https://gitlab.dusk.network/dusk-org/tech/issues/2

Following the notes on the paper: Source: 2008 Hisil–Wong–Carter–Dawson, we need to give support for all of the Twisted Edwards Point Operations.

The list will be:

• Point Addition.
• Point Subtraction.
• Point Doubling.
• Scalar Multiplication per Point.

It's also important to follow the guidelines explained in #47 to enable easier further implementations.

After continuous review of the possible algorithms, the decided algorithm will be the one implemented by 'E. Savas, C. K. Koc', :- 'http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.75.8377&rep=rep1&type=pdf'

The chosen Montgomery modular inverse algorithm divides the fore computation into two parts, Phase 1 & Phase 2.

Problems to address:

• Outline values for both phases s.t. they multiply to 1 (mod p)
• Determine whether the output values will be even or odd. Initial even values must be divided by 2 and then 2p is used for modulo

Another important step on the implementation is to create the conversion FieldElement <-> RistrettoScalar.

RistrettoScalar struct was implemented by Dalek devs on Curve25519. So we can maybe review it and pick it or implement it by ourselves.

Create a code snippet that works as follows:

Given a Scalar a that, provided only a · G, you prove you know a without revealing a.

Preferably with bulletproofs

This pull request is mostly covering refactoring and doing a replacement of the code in line with the new curve model, as well as a change in terms. Whether this is kept open or not, as I continue to commit is not very important. However just ensure that the same refactoring isn't done on other forks, as it would be unecessary.

Whilst perusing, I have come across 4 aspects in the code which I would like to go through with @CPerezz before making changes.

Extra work that has been done in addition to refactoring, includes:

• Showing the curve derivation constants and the modified script
• Build python script for new point operations with Sonny curve

Describe what you want implemented Implement https://github.com/zkcrypto/ff traits on Scalar type

Describe "Why" this is needed A clear and concise description of why you need this to be implemented We would like to use Sonny for circuits in https://github.com/microsoft/Spartan. Spartan requires scalars to implement the ff traits. If we implement the traits in Spartan then we need to create a wrapper type.

Describe alternatives you've considered Implement Scalar wrapper that implements traits in Spartan.

Additional context The source on github also seems to be out of sync with the crate with the same version number published to crates.io. Can we get a new release?

Thanks.

Describe what you want implemented Scalar::from_bytes_wide.

Describe "Why" this is needed A clear and concise description of why you need this to be implemented We would like to use Sonny for circuits in https://github.com/microsoft/Spartan.

Describe alternatives you've considered curve25519-dalek but that library is not ZK friendly.

Additional context The source on github also seems to be out of sync with the crate with the same version number published to crates.io. Can we get a new release?

Thanks.

The Zerocaf paper is now centric around Fq arithmetic inside of Fq circuits. This is to be finished and put into Review prior to an IACR.

This Epic will have to include iterations of each of the sections and then their individual review.

It would be nice to have an implementation that returns an iterator over the 4 coordinates of a RistrettoPoint or an EdwardsPoint.

Ex:

use zerocaf::edwards::EdwardsPoint;
use zerocaf::traits::Identity();
let identity = EdwardsPoint::Identity();
identity.into_iter().map(|coordinate| do_something_with_cooord(coordinate)).collect();

Currently, we need to:

• Add some docs about how Ristretto works and some code examples on the ristretto.rs file.
• Review all of the library comments in order to make sure that they are correct.
• Refactor the examples of the library and include a ECDH one.