Notes on anonymous credentials

Best anonymous credentials that don’t use pairings: Single show, no attributes, symmetric issuer: Privacy Pass; uses VOPRFs Multi show, attributes, symmetric issuer: CMZ14 (original, https://eprint.iacr.org/2013/516)/CPZ19 (group element attribute variant, https://eprint.iacr.org/2019/1416); uses “algebraic MACs” and categorically supercedes U-Prove Single show, attributes, publicly verifiable: Anonymous Credentials Light; uses an Abe signature variant For multi-show with attributes and public verifiability, as far as I know you need to use pairings to get randomizable signatures. The best general credential of this type might still be the first real one, CL04 (https://cs.brown.edu/people/alysyans/papers/cl04.pdf) but probably now you’d instantiate it with Pointcheval-Sanders signatures (PS16, https://eprint.iacr.org/2015/525 + PS18, https://eprint.iacr.org/2017/1197 tweaked for better proofs) which allows for constant-size credentials. ...

March 26, 2020 · 2 min · George Tankersley

Notes on threshold signature schemes

A threshold signature allows a subset t of a group of n possible signers to collectively produce a signature for the entire group. The simplest ones tend to use some distributed key generation (“DKG”) based on verifiable secret sharing (“VSS”) to construct the keys and secret inputs to a Schnorr signature in a distributed manner. There have been a lot of these, and recalling all the Feldman-this and Pedersen-that gets confusing. The following seem to be the core papers in the field of discrete-log threshold signatures: ...

October 18, 2019 · 2 min · George Tankersley

Adding privacy to legacy protocols with zero-knowledge proofs

Last January, Adam Langley did a really cool thing. He grafted zero-knowledge proofs onto an already-deployed, non-upgradable hardware system, thereby gaining privacy that the original design never allowed. I am VERY EXCITED ABOUT THIS. It’s an existence proof for all kinds of amazing things. The problem The specific problem here is that some websites want to know what type of security key you’re using. Security keys support this by showing the site a signed “attestation certificate”, which sounds fine…until you consider the details. The attestation key is burnt into the device at manufacture time, and will be the same for every attestation. Attestation certificates are supposed to be issued in large batches, but nothing holds vendors to it. Even if vendors are honest and competent, 100k possible identities isn’t very many in the face of modern tracking techniques. And worse: each site gets to make very granular decisions about which brands and batches of keys to trust, which goes against the idea of a standards-based web. ...

August 18, 2019 · 5 min · George Tankersley

Efficient Private Contact Search

Recently, a friend and I indulged in the very normal spring weekend activity of discussing the Signal contact discovery problem in the park. The contact discovery problem is this: a service holds a list of all registered users, and an individual user has an address book. The user wants to learn which of their contacts is also registered for the service without leaking the contents of their address book to the service, and the service wants to provide that information without publishing a global list of users to anyone who doesn’t already know them. The typical app’s solution to this is for the user to upload their entire address book to the service. ...

April 22, 2019 · 5 min · George Tankersley

A Macaroons Reading List

Macaroons are one of my favorite cryptographic constructions. They were almost the first one I really understood, and they heavily influence my designs for anything involving authorization. There’s a lot to love about macaroons. They’re elegant and fast. They’re secure and easy to reason about. They offer new capabilities over what was there before while sacrificing nothing. They are the anti-JWT, and they are tragically underused. A macaroon is a bearer token consisting of a list of statements and an HMAC (a type of secret-keyed hash) of the whole list. The statements (called “caveats”) are restrictions on what the bearer can do. They can be anything, like “must be logged in”, “not after next Tuesday”, “once per hour”, “read but not post”, or “can only see the /catpics directory”. When a server protecting some resources sees a macaroon it issued, it can check the HMAC to see that the list is valid, then compare the restrictions to the bearer’s request. ...

December 14, 2018 · 3 min · George Tankersley