Adventures in Porting: GnuPG 2.1.x to Android!

PGP started with Phil Zimmerman’s Pretty Good Privacy, which is now turned into an open IETF standard known as OpenPGP. These days, the reference OpenPGP platform seems to be GnuPG: its used by Debian and all its derivatives in the OS itself for verifying packages and more. It is also at the core of all Debian development work, allowing the very diffuse body of Debian, Ubuntu, etc developers to communicate and share work effectively while maintaining a high level of security. It is also used for email encryption in Thunderbird + Enigmail, Apple Mail + GPGMail, GNOME Evolution, KDE KMail, Microsoft Outlook + Gpg4win.

Yes, encryption means lots of ones and zeros that you can't read!

After actively using GnuPG for a few years, I thought it would be a good idea and not too difficult to port it to Android. I dove in and started with the code from git since I was hoping to involve the GnuPG developers. I had recently seen that they were stopping development on the 1.4.x branch, so the 2.1.x branch seemed like the logical choice to give us a reasonably complete OpenPGP implementation. Now I am happy to say we have it working on Android, with a couple of loose ends to tie up in order to get everything working.

One thing I do have to say is that GnuPG has evolved into a large and elaborate project that not only covers OpenPGP, but also PGP/MIME and things that have nothing to do with PGP like AES symmetric encryption and S/MIME email cryptography. That means it know is made up of many moving parts. It uses many libraries: libassuan, libgpg-error, libksba, npth, openldap, pinentry, and more if you want. It is also made up of a handful of programs to handle different aspects: gpg is the command line interface, gpg-agent seems to be the central key handler and task broker, dirmngr manages connections with directories like OpenPGP keyservers, pinentry handles getting passphrases from the user, etc.

The complexity does not stop there for our purposes: we need a Java API so we can make an Android app. So next up we built the GPGME (Gnu Privacy Guard Made Easy) library to provide a C/C++ API which is then wrapped in gpgme-for-java, a JNI library to make the GPGME functions available in Java. And just to heap on the layers, we are making a GUI on top of all that so that when you use it, you have no idea that all these little pieces that I have just described are even there at all.

18 comments for “Adventures in Porting: GnuPG 2.1.x to Android!”

We started this project because of these specific features that APG lacks:

* no method for uploading personal public key
* no method for signing other people’s keys
* no method to view signatures on a key
* no PGP/MIME support

Since signatures on keys is the essential building block of the OpenPGP Web of Trust, we really wanted an OpenPGP app for Android that fully handled all of the standard operations related to signing and verifying keys. There are also many other features in GnuPG that we then get for free, like S/MIME support, but we aren’t necessarily targeting those.

Let’s also not forget performance! With our work on the SecureSmartCam project, we need a fast way to gpg encrypt large video files, or perhaps even encrypt in realtime via a pipe. This is just not possible with the Java-based APG.

Those two look promising, but our mission is not so much about developing and testing new cryptographic algorithms. Instead, we focus on making crypto best practices widely available and easy to use properly.

You don’t have to pay anything, there is already many XMPP clients that support OTR encryption. Gibberbot and Beem on Android; Pidgin on Windows, Mac OS X, GNU/Linux; Adium on Mac OS X; etc. This paper from the OTR authors outlines why OpenPGP is not well suited to streams like XMPP chats: http://hatswitch.org/~nikita/papers/otr-wpes.pdf

We have the command line gpg working on Android for everything that doesn’t need a password (encrypting, verifying, searching keys, etc.). We are just picking up this effort again right now, starting with implementing the gpgme framework for C++ and Java, and creating a pinentry for Android, so we can feed passwords to gpg. Once we get that working, we’ll start in on creating Android Intents so other apps can trigger actions. After that, we’ll then start working on developing the whole GUI for GPG.

I can’t send email on the onion tormail onion page as there is no send or compose email option so is there a android email client to use or do I configure my droid email client? Ex gmail app or stock email client on my smart phone? Can someone help me please

Thank you very much for the great and so important work! On the K9-Mail site is a discussion taking place, that supporting PGP/MIME would require major changes of the whole architecture of the programm. What is your idea at the moment for implementing it? Which email client do you have in mind?

I was thinking that K-9 would be the best candidate for PGP/MIME support. Too bad its such a big project. Is there interest in taking it on with the K-9 community? We would certainly do what we can to support the effort, anything from tailoring the PGP/MIME API to K-9 needs to direct code contributions.

Does any have other recommendations for Android email clients that could potentially support PGP/MIME?

This is the issue, where K-9 developer are discussing MIME integration. Maybe some of you could join the discussion and figure out how to solve it. Unfortunately I have no programming skills, but I would like to help in any other regard.

@hans
you could use r2mail2 for android. it also support pgp/mime and certificates. it is based on k9mail and developed in austria. one reason for me to trust this app. i do not like all these US apps :-/

r2mail2 sounds interesting, we are always happy to see more people work on privacy-enhancing software. Hopefully they will contribute back their improvements to the k9mail project so we can build upon them. As far as I could tell, r2mail2 is currently proprietary software. That means you have to blindly trust the authors. As a holder of both Austrian and US citizenship, I don’t think that that model of trust works any more. Basically every government has a spy agency, and they are more and more pushing hard in the same direction as the NSA, GCHQ, etc. If the source code is open, it can be audited. That also means that the build process can be verified as well, which is perhaps more important.