George Tankersley

This is one of my favorite poems. There’s no interesting story behind it: I picked up a book for its cover (at a time when I wasn’t accustomed to buying books of poetry) and it’s stayed with me ever since. Working with computers for long enough imposes a particularly systematic way of thinking. I like to be reminded there are others. How to Know Birds The place you’re in The time of year ...

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. ...

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: ...

Despite their name and ostensible purpose, social networks aren’t very human. To companies, engineers, and advertisers, the emphasis has been on network, not social. We flatten users into profiles and communities into graphs. While it’s certainly convenient for databases, it’s an utter failure at capturing the nuances of social interaction—when you force people to interact in inhuman ways, you can’t be surprised if you get inhuman behavior. How do we fix it? I’ll tell you up front that I don’t have answers. It’s looking pretty grim out there. From here in 2019, it looks like may not get to keep both global social networks and a functioning society. ...

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. ...

If someone has access to your Google account, they have immense power to track or impersonate you. Whether they broke in, stole a computer, or you gave them access and now want them gone, here’s what you can do to kick them out. First, get a computer you can trust Because we’re going to generate new passwords and security settings, you’ll need to use a computer you trust. This is very situational; someone who is intent on stalking you might have installed spyware on your computer that will tell them what your new passwords are, so you shouldn’t use your normal machine when you do these resets. If it’s less of a personally malicious situation, you probably don’t need to worry about this! ...

I’ve spent many hours working on tech conference talks over the past few years. I’ve spent even more time than that helping other people refine their talks, everything from startup pitches to lectures on cryptographic research, and after a recent week of conferencing I’ve decided to write down things I end up saying a lot. Here’s a condensed form of my usual speaker coaching, in no particular order: Explain who you are! I may be at your talk but that doesn’t mean I have any idea why I’m listening to you about this topic. Knowing the context helps with understanding the talk. Your first couple of slides should be an on-ramp rather than criticial starting information. Your audience is still checking Twitter after the last talk, and you owe them a fair chance to start paying attention. An opening joke serves well here because laughter makes people look up. Tell people where you’re going in an early slide. Show the final benchmarks, demo the shiny feature, give a description of the tool you released. Establish the prize for paying attention. Be willing to handwave. No one is going to challenge your definition of terms while you’re speaking, and a friendly audience is along for the ride as long as you keep it moving. Rabbitholing on some complex conceptual dependency is a particularly common failure mode among speakers who are used to giving academic talks. Live demos are risky! Always have a backup for when it fails. Some good alternatives are to record a video, keep the bash history for a run you did already, or (sneaky) use VMs or scripts that only look live. Be careful with your choice of font. Contrast is important. Size is important. Remember the colorblind. If in doubt or a hurry, use only black on white and make it large. Speak slower than you think you should. The best speaking advice I’ve ever received is “if you don’t feel a little silly, you’re talking too fast.” Don’t put too much information on one slide. But if your slides must have a lot of information on them, give people time to read before you start talking about the next thing. Relax. You’re here because the organizers want you to be. Your audience is on your side. The speaker dinner is going to be awesome! Don’t ever miss the speaker dinner. It’s the best place to meet other people who are really into the thing! Sacrifice making your slides pretty if it means you’ll make it to dinner.

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. ...

Did your last Yubikey just break? Perhaps you forgot an offline backup password. Maybe you’re just tired of living like a spy and never using smartphones. Whatever it is, you’re here, and you’re finally ready to give up on PGP. That’s great! We’re here to help! No one was sending you encrypted emails anyway, so that’s easy enough. But the most widespread uses of PGP are machine-oriented, for needs like package signing and local file encryption. I recently got into this again on a thread that mentioned deprecating Go’s OpenPGP package and people always ask the same question: if not PGP, then what? ...

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. ...

Introduction Tor is an anonymity and censorship circumvention tool that uses a network of relays around the world to mask the origins and destinations of traffic. It’s used by researchers, journalists, and activists all over the world, as well as by ordinary people who want to keep their internet use private. There’s a lot of writing about Tor’s protocol or its use as a privacy tool, but not a lot of writing about Tor as a codebase. I’ve been a minor contributor to the project in the past, and through various other projects I’ve had a lot of opportunity to spend time with the Tor code and specs. ...