GnuPG is not a library

related: cryptography , embedded , gpg , libraries , encryption

NOTE:  I know nothing about this topic.

PGP Support in E-mail Clients Sucks

There are countless complaints about the notable lack of PGP support on mobile devices.  Your fancy iPhone might be the lifeline between you and the office while you’re traveling… but a fat lot of good that does you if most of your work communication is encrypted.  Which it should be.

Even on desktops, PGP support in e-mail clients is somewhat lacking.  You can use the Enigmail extension to Thunderbird – it’s very nice, but a little unstable.  You can use GPGMail to extend Apple Mail, but it is wracked by problems.  And if you want to use webmail, you could try the Firefox extension FireGPG – but it was plagued by so many problems that it has been discontinued.  Windows has a similar application, Gpg4win, that I have never used.

Why is PGP support always implemented as a hack extension to e-mail clients, instead of nicely built in?  And why is it so rare and underdeveloped on mobile devices?  Apparently, because GnuPG is not a library.

GnuPG Is Not Very Divisible

GnuPG is the Free Software implementation of the OpenPGP standard.  It is the one true implementation that most of us ‘common people’ use – layfolk don’t generally buy the proprietary PGP program.

The GnuPG project is split up into parts, but can mainly be considered two halves:

  • libgcrypt – A cryptography library
  • gnupg – An application that implements OpenPGP

In my quest for PGP support in an application, I wrongly assumed that libgcrypt was a “PGP library”.  This is totally incorrect.  libgcrypt implements hashing algorithms, symmetric ciphers, and asymmetric ciphers (private/public key encryption).  It has nothing to do with PGP.

GnuPG, the application, does all the rest.  And all the rest is A LOT.  It contains a key management, storage, and search agent (gpg-agent), and an OpenPGP message and packet decrypter/encrypter, and handles importing and exporting keys, and implements cryptographic signatures, and countless other things.

GnuPG is well-written and highly portable, and seems to run on many platforms.  But it is a command-line tool.  It does the trick when you are embedding it into native Linux applications like elm/pine/mutt, but nicely wrapping a command-line tool in a GUI tends to be trickier than one might expect.

The GnuPG folks eventually realized that, and released GPGME.  GPGME is basically the GnuPG application compiled into a library.  This certainly makes it easier for desktop applications to tie into GnuPG, but it still requires the ability to build the GnuPG application for your target.  Because GnuPG is quite large, not particularly modular, and designed for a POSIX build environment, this still isn’t the best answer for embedding PGP functionality in small devices.

The basic steps of implementing OpenPGP remain locked up in GnuPG in a way that they can’t realistically be split out.  I have spent some time in the GnuPG source code, and see that they it is not split up internally into standalone modules.  Because of the tremendous complexity of implementing *all* of OpenPGP and mixing it with key management, simple concepts like “split a message into packets” are not so simple at all.

Decrypting E-mail Does Not Require All of OpenPGP

OpenPGP is a very, very flexible standard.  A message from one client to another can be encrypted in hundreds (maybe thousands?  tens of thousands?) of ways, and still be valid OpenPGP.  The hashing algorithms are selectable, the symmetric ciphers are selectable, the asymmetric ciphers are selectable.  And there are plenty of adjustable options with each.

But most people aren’t using all of that.  From the few thousand PGP-encrypted e-mails I have received over the years, there have only been a handful of combinations used.

Most of the people I communicate with have keys that were generated within the last few years using the defaults from GPG 1.x – which means to import a secret key, most people I know only need support for:

  • Hashing their passphrase with SHA-1 (iterated + salted)
  • Decrypting secret key exponent with TripleDES

That’s it.  The rest is just reading buffers and filling out some structures.  That plus a support for DSA decryption and you have yourself a partial implementation of OpenPGP that will work for decrypting a large percentage of e-mails.

We Could Really Use a PGP Library

It may be true that, for most cases, GnuPG is available for your platform and does the trick.  But this isn’t always the case.  And more than that, I believe there are many applications that would embed at least some PGP functionality into themselves if it didn’t require dependency on another application.

We need a library that can perform just a few basic tasks of understanding PGP:

  • Split a message into packets
  • Decrypt secret key packets
  • Extract DSA/RSA/Elgamal variables from key packets.
  • Decode DSA/RSA/Elgamal encrypted data packets.

Even just this, just the ability to decrypt the most common PGP messages, would be a big advantage!

At least, it would be a big advantage for me.