Crypto on gtank writes here

Notes on anonymous credentials

Thu, 26 Mar 2020 20:06:25 +0000

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.

Notes on threshold signature schemes

Fri, 18 Oct 2019 02:33:40 +0000

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:

Adding privacy to legacy protocols with zero-knowledge proofs

Sun, 18 Aug 2019 22:24:19 +0000

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.

Efficient Private Contact Search

Mon, 22 Apr 2019 16:08:39 +0000

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.

A Macaroons Reading List

Fri, 14 Dec 2018 03:47:26 +0000

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.