[Warning: Technical Long-Read] ZeroCaf is a pure Rust implementation of the Doppio Elliptic Curve using a Ristretto Mapping, by the Dusk Network Core Team
Dusk Network is proud to release ZeroCaf, an open source library used to implement the most secure proofs of knowledge.
ZeroCaf is an open source library that allows the developer community to implement cryptographic protocols over the Doppio Elliptic Curve using a Ristretto mapping. The goal of ZeroCaf is to achieve zero-knowledge set inclusion proofs, which are the most secure proofs of knowledge!
We have taken great care to prepare extensive documentation and even an User Interface to accompany our release. With the aim of pushing forward the crypto community. For any specifics, you can report those on our Public Github Repository.
Why is it being constructed?
If the desires of a cryptographic protocol are particularly innovative and unique, there is often a need to construct the fundamentals of any created cryptographic library and tailor it towards a specific goal. In our case, no pre-existing libraries contained the necessary works for our desired outcomes. Since the ZeroCaf has so many layers in its protocol it was first necessary to build a framework or ‘cryptographic skeleton’ and once this dictated our road map. The various components of ZeroCaf were selected, as one of many variables, to work aggregately towards set inclusion proofs.
Bear with us, it gets a bit technical first!
How does it work?
ZeroCaf hosts a collection of predefined cryptographic operations for a specific Twisted Edwards Elliptic Curve across a specific prime field. The form of the Elliptic curve chosen allows for the fastest known arithmetic cure operations. However with the Twisted Edwards curve, there is sacrifice in security, which stems from each point on the curve is being part of a subgroup of prime order r, which is the number of points in the sub group, and the curve itself is a group of order n. When working with the point operations on the curve, coordinates within the subgroup are produced but each point has a cofactor, which is denoted as h. The group order n, divides the subgroup order r, to produce h. Which is represented by: r*h = n. This means that each point on the curve has a cofactor. When the cofactor is not 1, any protocol requires careful analysis as there are drawbacks in security as well as complications in implementation. For example, if an attacker sends a point which has an order divisible by h and a user multiplies this point by their chosen scalar to generate a private key, then the computed point will be known to the attacker and potentially the chosen scalar as well. With respect to implementation barriers, a prominent case is the the Curve25519, which has a cofactor 8. Consequently, when performing a Diffie-Hellman key exchange over the Curve25519 the Diffie-Hellman private keys must be chosen as multiples of 8, as this is ensures that the points will be in the proper subgroup.
As is previously mentioned, ZeroCaf is designed to host the fastest possible curve operations whilst simultaneously avoiding all of the drawbacks associated with having a cofactor such that h > 1. To achieve this we make use of Ristretto, which is a technique to construct prime order elliptic curve groups. The Ristretto protocol compresses the cofactor by adding a thin abstraction layer to allow small changes in code to ultimately omit the cofactor issues. This is achieved by having defined the Twisted Edwards curve over the ristretto scalar field, which means to perform every operation on the curve in modulo L, where L is the order of the Ristretto scalar field. L = 2²⁵² + 27742317777372353535851937790883648493. By expounding the operations in this manner, we can benefit from the speed of a non-prime order twisted edwards curve whilst not suffering the pitfalls of a cofactor greater than one.
An elliptic curve can equally be viewed as a function, so that certain inputs give certain outputs, where the outputs are defined by the varying inputs and the parameters of the curve. For Twisted Edwards, the equation is ax² + y² = 1+dx²y², where a = -1. As can be seen from the equation, varying x inputs will provide y values which correspond to give coordinates. A specific point on the curve can be represented by various coordinate systems. The coordinate system we’ve chosen to adopt is Twisted Edwards, as this provides high speed operation by introducing extra auxiliary points. For some better tangibility to the how extended coordinates differentiate in terms of structure and computing expense, they can be compared to affine coordinates. Affine coordinates are represented as (X,Y), where as extended coordinates are denoted ad (X,Y,Z,T) and where adding two points in affine coordinates costs 10 field multiplication, 1 squaring and 1 constant multiplication; it takes only 9 field multiplications and 2 constant multiplications in extended coordinates. Our main goal, when developing a cryptographic protocol, is to focus on the protocol itself. This includes good modularity and not forgoing any speed in operations.
ZeroCaf defines a variety of point operations on the Elliptic Curve, as the library provides and an easy-to-use API, these operations can be taken and manipulated to Elliptic Curves of varying parameters. ZeroCaf predefines all of the maths, which means any user who wishes to use the code can do so and modify it to their protocol without the need to refactor the arithmetic operations. This is particularly useful when it comes to application maintenance and ensuring robustness, as it alleviates the workload to the implementer.
As shown before, the coordinates of a point are displayed in numbers. ZeroCaf, however, works over a finite field which means that all of the coordinates are represented as Field Elements instead of numbers. These Field Elements have their own rules for each operation and the primary reason for the use of Field Elements is to represent each point in the Ristretto scalar field. All of the operations between are performed modulo of the prime of the field. ZeroCaf provides support for Field Elements and all of the operations that you can perform with them, from the addition to modular inverse or modular square roots. The modular inverse in particular is the grassroot algorithm which permits the representation of points into the Ristretto scalar field.
The library also gives support to all of the operations over the curve sub-group, which is another finite field that works modulo: 2²⁴⁹ — 15145038707218910765482344729778085401, denoted as the prime of the Sub-group. Currently, the library is able to process every operation regarding Field Elements and Scalars, which is both tested and documented whenever a new operation over the curve is defined.
It’s also important to mention that benchmarks have been done to test the curves operational execution speed. Obtaining results which are close or equal to the ones obtained performing the same operations with high speed ECC Rust libraries like Curve25519-dalek.
We obtained successful execution times for all of the library operations. Some examples are:
- Twisted Edwards Point addition takes approximately 972 ns
- Field Element Modular inversion took 64.131 us.
What is it used for?
Elliptic Curves can be used for encryption, decryption, digital signatures and other undertakings. The primary use case in the Dusk network is for private key generation. Public keys are generated using the Elliptic Curve, where a private input is given and kept secret by the user. As previously explained, the library has been built such that the speed and security of this key generation are of the highest regard in the Dusk Network protocol. A private key is simply a random Scalar value chosen between 0 and L-1, where L is the order of Ristretto Scalar field. This private key is then multiplied by the coordinate base point of the curve, g, and gives an output known as the public key. Defined by x*g = s, Where the public key S is a coordinate on the Elliptic Curve. The relationship between the secret private key x and outputted public key s, is known as a private-public key pairing. The most significant aspect of the pairing is that if given the coordinates of s and the base point g, there is no way to feasibly compute the input x. Each private key x, computed by a user and kept secret, corresponds to a public key s which can be made public.
For set inclusion proofs, a user can prove that their private key corresponds to a public key without disclosing the former. An example within the Dusk network could be the whitelist on a security contract, where a user needs to prove their inclusion of their identity to invoke contract user methods. In this scenario, the whitelist will contain the public keys of all potential members; the people wishing to become members will have to prove that their private key corresponds to a generated public key which is on the list.
A zero-knowledge proof is a protocol in which one party, the prover can prove to another party, the verifier, the validity of a statement, without conveying any information apart from that fact. If they zero-knowledge proof can be performed correctly then there is absolute security as no information, other than the fact, needs to be disclosed. For this to hold, the proof has to stop either the prover or the verifier from tampering with truthful fact.
The relevance of zero-knowledge in ZeroCaf is the need to construct a library which can perform operations, like those mentioned in the previous section, in zero-knowledge. Ristretto is also selected as it is suitable for implementing complex zero-knowledge protocols, whilst requiring only minimal changes in code. This property is well capitalised as part of the use cases of ZeroCaf in the Dusk Network protocol.
ZeroCaf uses a Ristretto ready curve and allow the use of a curve with a cofactor whilst omitting the problems that are associated with it — this can be as basic as any key-exchange protocol. A large part of contemporary methods to improve security are zero-knowledge proofs and each aspect of the ZeroCaf library is constructed with the goal to have operations and protocols performed in zero-knowledge. Subsequently, the operations can be used in bulletproofs, which fortifies the overall set inclusion goal whilst keeping security paramount. To perform tailored protocols when using the library, then arithmetic circuits are a prominent method of forming constraints. The operations in ZeroCaf are prescribed to support constraints without the need for binary decomposition of every point.
A large number of cryptographic libraries can be rather distorted and difficult to follow, especially if the techniques used by the creators are not well documented or based on ill-defined constants. However, one important aspect to the creation of ZeroCaf was to make sure each step was well documented and easy to follow for those who wish to use it. To achieve this, two types of documenting aims were made, one was to make the library viewed holistically and as a connected part of the cryptographic framework within the Dusk Network protocol. This was done by keeping a publicly updated roadmap of each and every significant step in the coding, where the road map would be defined 10 steps ahead so that current efforts could be seen as part of a future solution. On a more refined scale, each document was automatically added to the public library in real time, in the event that any of the developers overlooked some code pushing. The second type of documenting used to apply a reductionist approach when justifying methods in the code. This lead to having comments for each major operation of what they were and how they worked — often accompanied by links to academic papers where the methods are defined. This way, people can see a working implementation of a mathematical paper that in different circumstances they would have been unable to visualize.
The documents have been sent to the IACR and we will update as soon as the publication is approved.
Dusk — Technology for Securities
Dusk streamlines the issuance of digital securities and automates trading compliance with the world’s first programmable and confidential securities.