Popular Cryptography

It’s like this: Everybody ought to be able to use strong cryptography any time they’re going to send anything to anybody. Ideally it should just happen, by default, but let’s take baby steps. This is a messy rambling work diary on trying to put some of the pieces together to make that a little more practical than it is today.

Sorry, this isn’t introductory. Maybe when a few more pieces of the solution are in place I’ll be able to write a painless “Here’s how you can do secure messaging” piece. Let’s assume you know what public-key encryption is and how Web APIs and Android apps work, and go from there.

So, what are the pieces you have to pull together to make private messaging for everyone (PM4E) useful?

1. People have to have keys, and tools to take care of them.

2. People have to be able to find other people’s keys and have good reason to believe they’re the right ones.

3. People have to have an easy way to encrypt/sign messages to other people.

4. People have to have an easy way to decrypt/verify messages from other people.

What happened was... · I ran across two pieces of software that seem to represent good progress toward making 1 through 4 above work for ordinary people. First is Keybase, which I wrote up last month; it provides a directory structure for people and keys. Next is OpenKeychain, an Android app from Dominik Schürmann that provides a bunch of handy crypto functions. It turns out that two OpenKeychain-related projects are part of this year’s Google Summer of Code; I think this is a project with legs.

I’m trying to help out both projects in small ways here and there.

1. Having keys · The only really practical toolset I’ve found so far is from the Gnu Privacy Guard (GnuPG) project. They have command-line tools for those who like such things, and GUIs on Mac and Windows. I’m one of those “people who like such things”, and the gpg command-line is hunky dory on OS X and I suspect everywhere else it runs.

The back-end machinery behind it feels robust and smart and convenient; it pushes things into clouds in places that Just Work where that seems appropriate.

One of the hard bits here is that most people are going to need their private keys to exist on more than one place: Typically, at least one computer and at least one mobile device. Amazingly, this is getting close to being user-accessible; I moved my private key from my laptop to my Android by sticking it in Dropbox. I’ve started to believe that this sort of thing is perfectly acceptable, as long as the key passphrase never crosses the wire. But once again, it needs a point&click GUI.

The vendors own this problem · The GUI, well on OS X it’s sorta kinda usable; which means not remotely good enough for civilians.

And you know what, that’s not GPG’s fault, that’s Apple’s fault. And Microsoft’s and Android’s and iOS’s. That’s right: Now that we have good robust free back-end public-key infrastructure, it’s ethically incumbent on OS providers to ensure that their OS comes with a nice clean easy safe GUI so that people can make and manage their own keys; this obviously must not require any geek-level understanding about how the pieces fit together and work.

Also, every OS really has to come with an API for this functionality, that messaging software can call out to and get results that provide no-surprise privacy.

2. Finding other people’s keys · The PKI technologies have been around for a long time but, near as I can tell, this key-sharing and key-trusting stuff has been one of the biggest stumbling blocks keeping them from being useful. In crypto-geek culture they have “signing parties” where people (who typically already understand the underlying crypto voodoo) get together and perform command-line rituals to say that “Joe believes that this here really is Ali’s key” and then if you also know that Elias, whom you trust, signed Joe’s key, you can probably believe Joe about Ali’s key.

ROFLMAO. Yeah, gonna happen real soon now at Internet scale, and ordinary human beings are gonna climb right on board with that, yessirreebob.

But the Keybase.io directory I mentioned above has another approach that I think is a winner. You can search in Keybase.io and look up, for example, me, and discover a public key with my name on it, and also strong cryptographic evidence that the person with that key is also github.com/timbray and @timbray and the person who runs tbray.org.

Which means that if a bad guy wanted to slip in a fake key there, they’d also have to persuade Twitter and GitHub and some DNS machinery to play along simultaneously; it’d be really hard.

So I forked OpenKeychain and have started adding Keybase.io support for it; this is easy, because Keybase has a straightforward HTTP/JSON API and the people building are responsive to questions and suggestions. Also, OpenKeychain is one of the cleanest, easiest-to-understand codebases I’ve stumbled across in years. Thank you Dominik! Here’s what a Keybase key search in OpenKeychain looks like.

I’m assuming that Keybase will introduce proofs via Facebook and email and so on; at the moment they can’t do it on Google+, which has a bug that eats PGP signatures in posts. [Update: Nope, G+ seems to be fixed.] But unless I’m missing something, the finding-trustworthy-keys part of the problem is solved, or at worst on its way to a solution.

Now, Keybase isn’t perfect; it has a super-slick Web GUI, but to decrypt and sign stuff you have to store your private key with them; this makes real crypto geeks blanch in horror, and justly so, because if NSA comes in and waves compelling legal documents at Keybase, they could fiddle with the software in such a way as to give the spooks your private key. Anybody who thinks that isn’t a real risk has their head up their ass.

But the notion of crypto-in-JavaScript is thought-provoking and I have to wonder if there’s a way to do it safely; a combination of siting the Keybase infrastructure in a place out of reach of misguided spooks, and some sort of unfuckable dead-man switch, so that changes to trusted JavaScript code can’t be hidden.

And anyhow, Keybase doesn’t require you to store your private key with them, which is good, except for that means you have to use their command-line interface, which is also pretty good, except for civilians won’t use command lines, so that’s bad. So the same OS providers who should be providing built-in key-management software should also bloody well either support Keybase’s API (which is easy, I’ve done it) or some other logically equivalent key-lookup service.

3. Encrypting and signing · So I guess in an ideal world there’d be “encrypt/sign” buttons in my email and Facebook and Twitter and G+ and Instagram and Snapchat clients. Forgive me, but I find this hard to believe in; at least in the short term.

Well, except maybe on Android, which has this incredibly useful notion of Intents with which you can support “sharing”, my favorite write-up is Alex Lucas’ Share With Intents.

Android users have gotten used to seeing the Share icon beside pictures or movies or chunks of text or, well, anything; press it and you get a menu asking how you want to share. So, you can share a Web page to Twitter, or a photo to email, or a movie to Facebook, or, well, more or less anything to more or less anything.

OpenKeychain · It does much of what GnuPG does, has a reasonably-OK UI, and supports sharing: you can share from any other app to it for encryption/signing, and anywhere you can share text from, you can share to OpenKeychain for decryption/verification.

Once you’ve shared to OpenKeychain, you select who you’re encrypting for off one pick list, and which of your secret keys you want to sign with off another.

No, I don’t know why I’d want to encrypt a note-to-myself about marine maintenance. Yeah, the UI could be a little more compelling. But it works and it’s idiomatic Android tap-and-swipe.

Anyhow, when you’ve made those choices, you click the “Share with” button (yes, it should have the standard “share” icon on it) and you see another standard menu asking you how you want to send the encrypted version along.

4. Decrypting and verifying · Once again, OpenKeychain. But we still have a few problems. One is very specific to the decryption side. I bet that a lot of times, when you encrypt something, you’re going to want to drop the encrypted text into email. Which for a lot of people on Android means Gmail. And when you get that kind of message on Gmail, you quickly discover that <gasp> it doesn’t have a “Share” option. Bad, bad Gmail! Well... it turns out that if you copy a bunch of text from your email, then a “Share” button pops up, which is better than nothing, and would be better still if Gmail had a “select all” button, which it doesn’t.

Actually, the right answer is for Gmail to notice the PGP signature and just go and bloody decrypt the thing for you. In fact, lots of apps should, OpenKeychain has APIs and they’re under active development. Also, I wonder if it’s a problem that apparently everything crypto-related is GPL’ed; the choice of license seems perfectly appropriate for this domain, but lots of pieces of software that should use these capabilities aren’t GPL candidates. Anyhow, baby steps.

[Update: Dominik says that the OpenKeychain API code is actually Apache2. Win!]

The other problem is that to sign a message, and to decrypt a message sent to you, you have to use your secret key. Which, at the moment, means you have to type in your secret key’s password. Which is wrong, because typing in high-quality passwords on mobile devices is axiomatically wrong.

I’m not sure what the right solution is, and I’m not a deep enough security pro to evaluate the candidates. But I’m wondering if something PIN-based is appropriate, last time I checked, “something you know and something you have” is, in many contexts, better than the strongest password ever.

Another candidate is password managers, things like 1Password, KeePass, and LastPass. If you absolutely must type passwords into mobiles, you should only ever have to type one, and this is the effect the password managers produce. A few of the password managers are starting to get native-app integration, too; check the picture to see what I mean. LastPass’ native-app integration is based on clever use of Android’s accessibility APIs, another example of the curb-cut effect in action. I’m very impressed.

But there’s a problem, which is that sometimes it doesn’t work. In particular, it doesn’t work with OpenKeychain; sure, the LastPass dialogue pops up like you see in the picture, but something modal goes off the rails in a way that results in no decryption happening.

I like LastPass but I haven’t drilled down on its security policies; for example, I’m pretty convinced that 1Password couldn’t turn your data over to an overenthusiastic civil servant even if they wanted to, and that’s the bar I’d like to see any password manager meet.

Baby steps · In fact, there are a lot of chapters in this story that almost work, but not quite, just yet. But I’m still excited, because I think that the shape of a future in which anyone can have safe access to strong crypto, without having to understand it, is perfectly visible through all these early-stage bugs and shortfalls.

---

---

Contributions

---