Java Security Hole

Good solid cryptography is an essential foundation for sound business usage of the Internet, and essential to provide a sane privacy level. But the tools for Java programmers are in horrible shape.

OpenPGP · The crypto landscape is wide and disorderly, but in the area I most care about, private messaging, OpenPGP is central. RFC 4880 gives pretty crisp and clean coverage of how it works. So what we need are nice clean OpenPGP tools for Java-heads.

OpenPGP describes public/private key formats and what signed/encrypted messages look like. So there are four or less inputs to any PGP process: The key, the payload (to be encrypted and/or signed), the encrypted data (to be decrypted), and the signature (to be checked). I could write down a Java interface that would give developers what they need in a few minutes. It’s a little harder than you’d think because you need to handle streaming data, but this does not need to be a complicated interface.

I’m pretty sure this is possible because there’s an excellent open-source OpenPGP implementation that has a command line tool, so you can say things like gpg decrypt and gpg check; so give me a Java API to do that.

Case study · The problem I’m facing is that I want to check a Keybase.io proof (for geeks, here’s a compact JSON version). So, I have a payload, the JSON starting with:

{\"body\":{\"key\":{\"fingerprint\":

I have a signature, the start of which looks like this:

-----BEGIN PGP MESSAGE-----
Version: Keybase OpenPGP JS 0.0.1
Comment: https://keybase.io/crypto

yMLDAnicdZF/TBNXAMfb0jKs61bi+CFlw95cSKR0116vd+2mA7fEIiLoyMaWbvWO

And I have a key, whose ASCII form may be fetched from keybase.io/timbray/key.asc.

Thus, I need a Java method something like

boolean checkSig(byte[] payload, String sig, String asciiKey);

Wish me luck; I’ll need it.

The library landscape · Of course, Java comes a set of Security packages that can among other things can check signatures, but all over the Internet it says “Of course, to do X (for almost any value of X) you’re going to need an external package like Bouncy Castle” (which exists in Java and C#). Unless you’re on Android, where the Bouncy Castle version is hard to use, thus someone has obligingly provided Spongy Castle as a drop-in replacement. [Update: Explanation in the comments.]

Hokay then, let’s go spelunk through the Bouncy Castle documentation and tutorials to figure out how to check that signature. Well I tried, but man, it’s far from obvious. Part of the problem (and this seems to be true a lot in crypto software) is that the libraries provide soup-to-nuts implementations of a huge swathe of crypto stuff, of which OpenPGP is just a corner case. And since this is all written by deep-crypto nerds (whom I admire immensely) you get an effect where you sort of have to understand everything to understand anything.

I’m never going to be a deep-crypto nerd, but I understand things at a conceptual level and, with the help of RFC4880, I think I understand key structures well enough to write code to build them and pick them apart.

There’s a Java OpenPGP library over at Apache Commons, but its functionality is limited and it seems very lightly maintained.

So, how hard is it to use Bouncy Castle to do basic OpenPGP messaging stuff? Let’s look at the excellent OpenKeychain Android app, which does just that. The openpgp subtree has 23 classes containing 15K lines of code.

It shouldn’t be this hard · At this point, since I’m interested in Android clients, I’m in Java-land. I don’t know if the picture in other languages is as grim as it is here. But if someone wanted to give what’s maybe still the world’s most popular programming platform a major shot in the arm, a tractable OpenPGP API for mere mortals would be huge.

But maybe I’m wrong · You know what would be great? If someone stuck up their hand and said “you noob moron, just grab this here library and use these five lines of Java and you’re done.” Not holding my breath.

What’s more likely is that someone says “A simple generic API will leave it open for developers to use it wrong and they think they’re getting good encryption when they’re not.” But I’m deeply unconvinced, I think it’s just a hole in the software inventory.

---

---

Contributions