What we really need is somebody to come along and put together a library to make it easy to use gpg in your application. They could call it "GPG Made Easy," oh wait:

"GnuPG Made Easy (GPGME) is a library designed to make access to GnuPG easier for applications. It provides a High-Level Crypto API for encryption, decryption, signing, signature verification and key management. Currently it uses GnuPG as its backend but the API isn't restricted to this engine; in fact we have already developed a backend for CMS (S/MIME)."[1]

[1] http://www.gnupg.org/related_software/gpgme/

GnuPG was never made to solve the problems of the authors of commercial software. It's made for GNU (Gnu is Not Unix) systems, in match with all ideological goals of GNU.

I earn for living producing a closed source code, I do use the GNU software in my day-to-day work but I know I can't use GNU libraries in my projects.

Complaining that GnuPG is not made to be convenient for the BSD-like library uses reflects OP's serious misunderstandings of the basic premises of GNU and BSD.

Not to mention that the author posits that his selection of "what's enough" for his use case would be enough for other use cases. I claim that he doesn't actually need an OpenPGP support as long he says that the small subset would be enough for him. He just needs some library to solve encryption and decryption in his limited scenario. He should use some other (BSD-like licensed) crypto-library and develop on it. But somehow I suspect even if somebody would then implement what's enough for him, the result wouldn't be open-source. You know, BSD licenses don't force you to do so.

Moreover I belive that OP misunderstood which part of software does what, I've never heard that GPG ever did "split a message into packets."

I feel like the best way to attack this problem would be to use GnuPG as a guideline to constructing an entirely new open-source library standard for PGP that can finally serve as a practical basis for widespread PGP encryption. It should also be under a permissible license, because otherwise we'll just get a repeat of everything that's happened with broken proprietary implementations and impossible to use open-source ones.

From the GnuPG FAQ:

"Can't we have a gpg library?

This has been frequently requested. However, the current viewpoint of the GnuPG maintainers is that this would lead to several security issues and will therefore not be implemented in the foreseeable future. However, for some areas of application gpgme could do the trick. You'll find it at http://www.gnupg.org/related_software/gpgme. "

Personally I also don't like the idea of people cutting out a "lightweight" subset of GnuPG. That will only lead to incompatibilities and security issues. Our phones can run 3D games, they should be able to cope with the full GnuPG.

The author implies that GnuPG should work the way he wants it to work. Now to be fair, it would be nice to have great GnuPG integration everywhere, including on iDevices.

But some perspective is needed here. GnuPG works fine in a POSIX environment. All popular platforms can handle that. This isn't the first command-line tool that needed to be integrated into a GUI. Seriously – that's all his complaint amounts to.

There may be a need for a library wrapper around GnuPG, but this complaint is not the need.

(subtitle: and it should be)

I share the pain. I'm using the executable instead - works well enough as long as you don't need high throughput public key encryption (if you do, you're doing it wrong), and you don't need high throughput public key signatures (that's actually a reasonable use case).

Anyone know of an alternative to gnupg?

There's netpgp (from NetBSD project) -- http://blog.netbsd.org/tnf/entry/netpgp

There's Peter Gutmann's cryptlib, which also supports OpenPGP (among a huge number of other things).

http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

It's also has a dual license.

I had GPG ported to pure PHP, believe it or not. It only currently supports encryption. I would love some help on this project. https://github.com/jasonhinkle/php-gpg

undefined

I was actually just trying to set up mutt with GPG a few moments ago. As a person who hadn't used GPG before, yes, it is a nightmare. Email encryption and signing should be common --- more common than not --- and the most prevalent tool for doing so being so daunting isn't helping.

I think this guy is right. Although a bigger problem is that PGP is available in two flavors: free and very expensive.

The problem with GnuPG IMO is that real obvious use cases (healthcare) are out of bounds because it isn't FIPS certified and isn't usable by mortals. Having an implementation similar to OpenSSL with an API, and use case that attracted organization willing to sponsor FIPS validation would be a big step forward. Your doctor could securely send you test results. Your credit card company could send your bill directly.

Consider: The #1 solution for email encryption in hospitals/healthcare is Zix. This is sad -- their solution amounts to attempting to transmit an email via SSL, and falling back to sending you a link to a webpage. Cheesy.

Unfortunately, that's not the way things are, and usage of PGP are generally limited to security professionals, paranoids, and crypto geeks.