schnorrkel

Schnorrkel implements Schnorr signature on Ristretto compressed Ed25519 points, as well as related protocols like HDKD, MuSig, and a verifiable random function (VRF).

Ristretto implements roughly section 7 of Mike Hamburg's Decaf paper to provide the 2-torsion free points of the Ed25519 curve as a prime order group. (related)

We employ the merlin strategy of type specific hashing methods with sound domain separation. These wrap Mike Hamburg's STROBE128 construction for symmetric cryptography, itself based on Keccak.

In practice, all our methods consume either a merlin::Transcript which developers create handily by feeding data to context specific builders. We do however also support &mut merlin::Transcript like the merlin crate prefers. We shall exploit this in future to adapt schnorrkel to better conform with the dalek ecosystem's zero-knowledge proof tooling.

We model the VRF itself on "Making NSEC5 Practical for DNSSEC" by Dimitrios Papadopoulos, Duane Wessels, Shumon Huque, Moni Naor, Jan Včelák, Leonid Rezyin, andd Sharon Goldberg. We note the V(X)EdDSA signature scheme by Trevor Perrin at is basically identical to the NSEC5 construction. Also, the VRF supports individual signers merging numerous VRF outputs created with the same keypair, which parallels the "DLEQ Proofs" and "Batching the Proofs" sections of "Privacy Pass - The Math" by Alex Davidson, and "Privacy Pass: Bypassing Internet Challenges Anonymously" by Alex Davidson, Ian Goldberg, Nick Sullivan, George Tankersley, and Filippo Valsorda.

Aside from some naive sequential VRF construction, we currently only support the three-round MuSig for Schnorr multi-signatures, due to all other Schnorr multi-signatures being somewhat broken. In future, we should develop secure schemes like mBCJ from section 5.1 starting page 21 of https://eprint.iacr.org/2018/417 however mBCJ itself works by proof-of-possession, while a delinearized variant sounds more applicable.

There are partial bindings for C, JavaScript, and Python as well.