Anon-Aadhaar, explained

How a zero-knowledge proof over the Aadhaar secure QR code lets someone prove they hold a valid ID, and share only the attributes they choose.

Rump Labs5 min read

On this page
  1. The problem it solves
  2. What the user already holds
  3. The statement being proven
  4. What the verifier learns
  5. Why the nullifier matters
  6. Where it gets hard
  7. Halo2 and Noir
  8. Beyond Aadhaar

The problem it solves

Aadhaar is India's national digital identity system. Services that need to know "is this a real resident, and are they over 18?" have traditionally answered it by asking for a copy of the card, then keeping that copy.

Every stored copy is a liability: a name, a photograph, an address and an identity number, sitting in a database until it leaks. The service only wanted one or two facts. It ended up holding everything.

Anon-Aadhaar is a protocol that lets a person prove those facts in zero knowledge, from data they already have, without handing over the document.

What the user already holds

UIDAI, the authority that issues Aadhaar, provides a secure QR code, printed on the card and included in the downloadable e-Aadhaar. The QR code carries the holder's demographic details and photograph, and it is digitally signed by UIDAI with an RSA key. Anyone with UIDAI's public key can check that signature offline.

That signature is what makes the protocol possible. The user holds signed data; the verifier trusts the signer. A zero-knowledge proof can connect the two without the data ever leaving the user's device.

The statement being proven

In plain terms, the prover claims:

I hold Aadhaar QR data carrying a valid UIDAI signature, and here are the attributes I have chosen to reveal. Nothing else.

Inside the circuit, that breaks down into four jobs.

  1. Verify the signature. Hash the signed QR data with SHA-256 and check the RSA signature against UIDAI's public key, all inside the circuit.
  2. Reveal selectively. Extract fields from the signed data and output only the ones the user opted into, such as whether they are over 18, or their state or pincode.
  3. Compute a nullifier. Derive a value from data in the credential and an application-specific seed, so one person produces one stable value per application.
  4. Bind the proof to an action. Include a hash of a "signal", such as a wallet address or a vote, as a public input, so a proof cannot be lifted and reused for a different action.

The verifier then checks four things: the proof is valid, the public key it was made against is UIDAI's, the nullifier has not been seen before in this application, and the revealed attributes satisfy its policy.

What the verifier learns

It learns that the prover holds a genuine, UIDAI-signed Aadhaar credential, plus the attributes the prover chose to reveal, plus a nullifier that is stable within this one application.

It does not learn the name, the Aadhaar number, the photograph or the address. Two different applications receive nullifiers they cannot link, so a person's activity in one service does not identify them in another.

Why the nullifier matters

Without a nullifier, one person could generate any number of valid proofs and look like a crowd: a dozen accounts, a dozen votes, a dozen claims on something meant to be one per person. Because the nullifier is computed deterministically from the credential and the application's seed, a second proof from the same person in the same application produces the same value, and the verifier can reject it.

The application-specific seed is what keeps that from becoming a tracking identifier. The same person in a different application produces a different, unrelated value.

Where it gets hard

  • Cost of the circuit. Verifying RSA and hashing the whole QR payload with SHA-256 are among the most expensive things to do inside a circuit. Proving time and memory on a phone or in a browser are the real constraints on the user experience.
  • Parsing in-circuit. The signed data is a sequence of variable-length fields. Pulling out the right one, in a way the circuit actually constrains, takes care; it is easy to write a circuit that reads the wrong bytes and still produces valid proofs.
  • Issuer keys. Verifiers must know which UIDAI public keys are valid and handle rotation, or they will accept proofs against the wrong key.
  • Trust in the issuer. The proof hides the data; it does not remove UIDAI from the trust model. If the issuer signs something false, the proof faithfully proves it.

Halo2 and Noir

The best-known implementation is written in Circom and proved with Groth16. Hridam Basu of Rump Labs has presented Anon-Aadhaar for the Ethereum Foundation's PSE team at Hacker House Goa, and at Devcon SEA spoke on it as a privacy-preserving identity protocol using Halo2 and Noir, two PLONK-family stacks with different trade-offs in setup, tooling and the cost of operations such as SHA-256 and RSA. Choosing a proof system covers those trade-offs in general; the full talk is on our talks page.

Beyond Aadhaar

The pattern generalises to any credential an issuer signs: national ID cards, the signed data in an electronic passport's chip, a university's degree certificate, an employer's attestation. Prove the signature, reveal one attribute, add a nullifier, bind it to an action. That is the core of the identity work we do: verifying users without warehousing the documents that prove who they are.

CryptographyIdentity

Next step

Tell us what
you're building.

Thirty minutes with an engineer, free. You'll hear what it takes, what it costs, and whether we're the right people to do it.