Anonymous Credentials from ECDSA - (Google, Dec. 2024)

Dear all,

I haven't seen any message on Google's "Anonymous Credentials from 
ECDSA" paper: https://eprint.iacr.org/2024/2010.pdf

Today I spent some quality time on it along with 2 colleagues and 2 
"friends" (read: chatGPT and DeekSeek).

The paper aims to offer a sort of "plug-n-play ZKP" functionalities, 
that would not require major updates on Google's TEE or on the Issuer's 
side (i.e.: no BLS12381), while keeping the performance acceptable. I 
find the approach very ingenious, you could tell that the algorithm is 
designed by a software guy and not a mathematician.

My summary:


- Issuance is a regular ECDSA issuance
- ZKP happens only in the verification step, as a proof is generated on 
top of the ECDSA signed VC:

- Issuance:
   - The issuer generates an ECDSA signature over the attributes 
(regular ECDSA VC issuance).

- Verification:
   - (Wallet) The user constructs a ZKP using the Sumcheck Protocol and 
Ligero Argument System.
   - (Wallet) The proof is encoded with Reed-Solomon encoding for 
robustness.
   - The verifier checks the proof without learning the signature.
   - The verifier ensures that the ECDSA signature is valid before 
confirming the credential.

- About Ligero:  "[Probabilistically checkable proofs (PCPs)]... 
arguments obtained via PCPs and IOPs have the advantages of not relying 
on public-key cryptography, not requiring a trusted setup, and offering 
conjectured security against quantum attacks."
- Performances: proof generation takes 750ms on X86 and 1.2 sec on a 
Google pixel 6.
- Claims to offer zk revocation, in future works
- The code is 25K lines of C++ (including 8K+ lines of tests), therfore 
I guess performance can be improved. Still closed source, the author 
(Matteo Frigo) told me (in a Linkedin Chat) that they're looking to 
release the code but it will take time due to Google's policies.

My take: we don't know yet if the algos work, if the code works, what 
Google will do with this and how this will be standardized (it will take 
years). Said that, I very much appreciate the approach and I sense that 
this line of thinking (building a ZKP on top of a regular ECDSA signed 
cred) could spawn some very interesting algorithms. Such approach has 
the obvious advantage that you keep most of the flows, the APIs and the 
infrastructure as it is, you just operate a surgical retro-fit (once in 
the verifier/relying party and once in the client/wallet) to implement it.


It's the first time I come across anything like this, I'd like to know 
if anyone else thinks and if anything similar has been seen?


Cheers,


| Andrea D'Intino | +45  21 62 79 18 | Project Manager
|https://Dyne.org think &do tank  | software to empower communities
| ⚷ crypto κρυπτο крипто गुप्त् 加密הצפנה المشفره