cloudflare / zkp-ecdsa

Proves knowledge of an ECDSA-P256 signature under one of many public keys that are stored in a list.

zkp-ecdsa: A Typescript Implementation of ZKAttest

ZKAttest proofs knowledge of an ECDSA-P256 signature under one of many public keys that are stored in a list without revealing which public key was used to sign the message.

Usage	Development	Cite This	Future Work

---

Usage

Ready to use ZKAttest proofs, follow this short guideline.

Step 1

Suppose you already have a signature of a message using ECDSA (P-256). Otherwise, create signature as follows:

// Message to be signed.
const msg = new TextEncoder().encode('kilroy was here');

// Generate a keypair for signing.
const keyPair = await crypto.subtle.generateKey(
    { name: 'ECDSA', namedCurve: 'P-256' },
    true, [ 'sign', 'verify'],
);

// Sign a message as usual.
const signature = new Uint8Array(
    await crypto.subtle.sign(
        { name: 'ECDSA', hash: 'SHA-256' },
        keyPair.privateKey, msg,
    )
);

Step 2

Then, insert your public key in a ring of keys. This allows to hide your public key behind the ring of keys. (In this example, assume the list was generated with valid keys).

import { keyToInt } from '@cloudflare/zkp-ecdsa'

// Add the public key to an existing ring of keys,
const listKeys = [BigInt(4), BigInt(5), BigInt(6), BigInt(7), BigInt(8)];
listKeys.unshift(await keyToInt(keyPair.publicKey));

Step 3

Now, create a ZKAttest proof of knowledge showing that

• the signature was generated using the private key, AND
• the public key is in the ring.

This proof does not reveal which public key was used during signing.

import { generateParamsList, proveSignatureList } from '@cloudflare/zkp-ecdsa'

// Create a zero-knowledge proof about the signature.
const params = generateParamsList();
const msgHash = new Uint8Array(await crypto.subtle.digest('SHA-256', msg));
const zkAttestProof = await proveSignatureList(
    params,
    msgHash,
    signature,
    keyPair.publicKey,
    0, // position of the public key in the list.
    listKeys
);

Step 4

After this, everyone can verify the proof is valid, which means the message was signed by the holder of an ECDSA key pair, but without identifying exactly which one of the keys in the ring was used to produce the proof. Do not disclose the original signature as it is already embedded inside the proof.

import { verifySignatureList } from '@cloudflare/zkp-ecdsa'
// Verify that zero-knowledge proof is valid.
const valid = await verifySignatureList(params, msgHash, listKeys, zkAttestProof)
console.assert(valid == true)

That's all.

---

Citation

This software library is part of the article "ZKAttest: Ring and Group Signatures for Existing ECDSA Keys" published at Selected Areas in Cryptography (SAC 2021) authored by Armando Faz Hernández, Watson Ladd, and Deepak Maram.

A copy of this paper can be downloaded at research.cloudflare.com or at the IACR ePrint 2021/1183.

To cite this library, use one of the following formats and update the version and date you accessed to this project.

APA Style

Faz-Hernández, A., Ladd, W., Maram, D. (2021). ZKAttest: Ring and Group Signatures for Existing ECDSA Keys. In: AlTawy, R., Hülsing, A. (eds) Selected Areas in Cryptography. SAC 2021. Available at https://github.com/cloudflare/zkp-ecdsa. v0.2.5 Accessed Nov 2022.

BibTex Source

@inproceedings{zkattest,
  doi       = {10.1007/978-3-030-99277-4_4},
  title     = {ZKAttest: Ring and Group Signatures for Existing ECDSA Keys},
  author    = {Faz-Hernández, Armando and Ladd, Watson and Maram, Deepak},
  booktitle = {Selected Areas in Cryptography},
  editor    = {AlTawy, Riham and Hülsing, Andreas},
  publisher = {Springer International Publishing},
  address   = {Cham},
  isbn      = {978-3-030-99277-4},
  pages     = {68--83},
  month     = {oct},
  year      = {2021},
  note      = {Available at \url{https://github.com/cloudflare/zkp-ecdsa}.
               v0.2.5 Accessed Nov 2022},
}

CFF Style

Find attached a CITATION.cff file.

---

Development

Task	NPM scripts
Installing	$ npm ci
Building	$ npm run build
Unit Tests	$ npm run test
Benchmarking	$ npm run bench
Flamegraph Profile	$ npm run flame
Code Linting	$ npm run lint
Code Formating	$ npm run format
Bundling Library	$ npm run bundle

---

Future Work

• Accelerate proof verification.
• Implement the proof in other programming languages.
• Remove dependency on native Bignum.

---

License

The project is licensed under the Apache 2.0 License

zkp-ecdsa's Issues

Questions about `generateParamsList` and `SystemParametersList`...

I see that the secLevel parameter of generateParamsList controls the number of items of the SignatureProofList.expProof therefore affects the proving time and the size of the proof. Are secLevels less than 80 safe to use? What's the trade off for proofs created with secLevel that are less than 80?

Do provers need to generate a SystemParametersList every time they're proving something? If not, is SystemParametersList like a snark verification key, i.e. generated only once for each circuit?

TypeError: Cannot call a class constructor without |new| index - TypedJSON error

When using writeJson(SignatureProofList, attestation.proof) on a browser environment, I get the error TypeError: Cannot call a class constructor without |new| index. For context, I'm using zkp-ecdsa in the following application within nextjs and after compiling it for "production", the code no longer works showing that error. During "development" (i.e. next dev) the code shows no issue so this is likely a JavaScript error after an improper transpiling from TypeScript.

how could I use this practically?

Reading throught the example it seems that I need to have access to the list of publickeys so that I can generate a proof of the signature.

So here is my thinking

1. Generate KeyPair
2. Submit public key to an endpoint that adds it to the list
3. generate Signature and submit to an endpoint that generates the proof
4. give the proof to the requester
5. requester submits proof to an endpoint that validates the proof.

This now adds some complexity, as I need to keep the list of Public Keys in memory / data store and reference that list each time. So I would need a mechanism that would scale. Or am i wrong in that thinking and there is a short cut to keeping the generated proofs valid whilst not maintaining the list.

Please close if there is a better forum for this.

Regards
Nicholas

How to prove staked ETH on beacon chain ?

Hello sir, i'm trying to understand how to use this library to prove that i staked 32 ETH on lido ? Can you add some code examples ?

Readme contains incorrect sample usage code

In readme's step 1, the usage code says "sign the hash of the msg" but based on test/zkpAttestList.test.ts it should be "sign the msg".

// Sign a message as usual.
const msgHash = new Uint8Array(await crypto.subtle.digest('SHA-256', msg));
const signature = new Uint8Array(
    await crypto.subtle.sign(
        { name: 'ECDSA', hash: 'SHA-256' },
        keyPair.privateKey, msgHash, // <---- should be `msg`
    )
);

Export/serialize feature

Once the zkAttestProof object has been created, it would be great to export or serialize it to be able to use it in separate mediums. However, the class object is fairly complex, and de/reconstructing seems like a bit of a challenge.

Are there any interest in adding this feature? For the current use case that seems to be used, it could be used as "backup" proof in case the generated key has been lost.

On the implementation of `proveExp()`

Hi,

It seems to me that there is a mismatch between the implementation of the function proveExp() in exp/exp.ts and the corresponding protocol from the ZKAttest paper (Proof of Scalar Multiplication, Section 5).

The difference is that in proveExp() the challenge variable challenge is the same for all instances, while in the protocol from the paper the challenge string c = (c0, c1) is different for every instance.

I do not know yet the security issues that it might raise (I have to read the protocol more carefully), but practically it means that inside the for loop (line 168, exp.ts), we will constantly evaluate the same branch for all i < secparam.

---

Suggestion: create a challenge for all instances i:

    ...
    // Compute challenge c = H (Cx, Cy, A, Tx, Ty)
    const challenges = new Array<bigint>(secparam)
    for (let i = 0; i < secparam; i++) {
        challenges[i as number] = await hashPoints('SHA-256',  [Px.p, Py.p, A[i as number], Tx[i as number].p,  Ty[i as number].p])
    }
    const allProofs = new Array<ExpProof>(secparam)
    let proof: ExpProof
    for (let i = 0; i < secparam; i++) {
        if (isOdd(challenges[i as number])) {
            ...

If this sounds right to you I can make a pull request with this change.