GnuPG is not a library
mrmekon.tumblr.com
mrmekon.tumblr.com
"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]
What's needed is actual good implementations of the clients. That's all really. The command line client is not perfect but its FINE. It's fast, it works, it does what it says.
The other clients sucks hairy balls.
People also fail to realize that to date, the PGP trust model is the only freaking viable trust model, because it's distributed, free, and the trust choice is up to the _user_ (and it happens to also have been around for more than a decade, that never hurts).
There's actual implementations of PGP/GPG for website authentication and transport encryption. There's implementations for package signing that _actually_ make use of the trust model (www.archlinux.org).
There's PGP SmartCards that are _way_ more secure than this little OTP token in your pocket, and it works for SSH too. But wait, there's more. It works for SSH authentication _using_ the trust model too (web.monkeysphere.info).
Oh, and last but not least GPG supports ECDSA, too. All this to say that PGP and the GnuPG implementation have a huge, underexploited potential, and that's probably due to ignorance.
As an example GPG saves its keys in a file. What if you want to put them in a database? Does GPGME allow a developer to do this?
"Does gpg allow you to export and import keys?"
Based on the comment below it seems my sarchasm was not evident. I should have written:
"Are you asking if gpg can import or export keys?"
Export a public key: gpg --export -a "UserName" > public.key
Export a private key: gpg --export-secret-key -a "UserName" > private.key
Import a public key: gpg --import public.key
Import a private key: gpg --allow-secret-key-import --import private.key
I've been looking for those. I can only find one from g10code / kernelconcepts.de - which is fine, but is exactly ONE vendor. The other one I found is the Yubikey NEO - less than two month old, and sold out for the next 2 months at least. Are there any other implementations that I'm missing? (Don't get me wrong - I've ordered from kernelconcepts before. But I don't like to be dependent on a single vendor)
> Oh, and last but not least GPG supports ECDSA, too.
True. Do you know if the PGPcard standard is supposed to be updated to support ECDSA too? Some standard require signing or encryption keys to be in an independent hardware module.
You disappoint me.
Either read the article and comment on it, or don't read it and avoid commenting.
But if you need to do gpg compatible crypto use the python wrapper for gpgme:
pygpgme exposes the gpgme library to Python. The product was started by
James Henstridge. Beside Python2 it supports Python 3 since v0.3 (March
2012). The wrapping is done using python's C interface directly without
using a generator tool like SWIG.[3]
To me, the whole idea of wrapping an executable with a library is completely backwards. The executable should do nothing but provide a command-line interface to a library.
I think there is definitely room for a reimplementation of gnupg inverted in this sense (similar to how libgit2[1] is currently reimplmenting git).
your other point is also not that convincing. smallish binaries usually have a very clear api. they can be called from every programming language without much effort.
coming back to pgp: you usually do not parse the same message over and over again. so you do not need to have any shared state for caching between calls to that executable.
> 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.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."
Your argument has nothing to do with the actual problem in the article, that running a command line application when you need a library is troublesome and restrictive.
Hell, if it was a library its license would matter far more than it does as a non-library.
His use case would be covered by a BSD-like licensed library, which is not compatible with GPL goals, so he picked the fully wrong target to complain about. It seems that this important distinction is not clear to the OP and to you.
Thunderbird, mentioned by you, actually uses GnuPG without problem. The very reason it can use it is because it uses it as a command line utility. If there were a library, GNU licensed, Thunderbird wouldn't be allowed to use it because of the license incompatibility.
Isn't Thunderbird's license MPL 2.0, which is GPL-compatible?
1) GPL/LGPL are not incompatible with iOS, they are incompatible with the App Store. I don't care about that. I was writing a GPL'd app, and I would be pleased with a GPL'd library. iOS was also not my only target. (response to one of your other posts)
2) The idea of 'what's enough' was for e-mail decryption only. Which is what I wanted to do. And I wrote an open-source OpenPGP library to do it: https://github.com/mrmekon/libsimplepgp
3) I don't need 'some library to solve encryption and decryption', I need 'some library to solve decryption of PGP-encrypted emails.' A partial implementation of OpenPGP, as a library. Other crypto packages don't support the OpenPGP packet format.
4) Read section 4, "Packet Syntax", the entire concept behind the OpenPGP format: http://www.ietf.org/rfc/rfc2440.txt
Updating your blog post with the link to your library would make the post much more relevant, weren't you able to do so?
I understood you "message splitting" like the plaintext or the ciphertext being split, which as far as I know neither is. RFC does use "packets" packets to denote segments as the "packet" with the key and the "packet" with the cypertext but I don't consider recognizing where which begins in order to process it is "splitting." I see now what you wanted to say.
Re "other crypto packages don't support the OpenPGP packet format" -- I understood that libgcrypt also doesn't, so wouldn't be more in the spirit of your goal (if it is) to have OpenPGP more widely used to base libsimplepgp on some BSD, Apache or similarly licensed crypto libarary?
"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.
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.
ffmpeg (LGPL): https://ffmpeg.org/trac/ffmpeg/ticket/1229
vlc (LGPL): http://waffle.wootest.net/2011/01/08/vlc-gpl-tuaw-wtf/
It is fully, 100% GPL-compliant to release a (L)GPL'd iOS application linked to a (L)GPL'd library, as source code, with instructions on how to build and load on your iOS device.
It is /probably/ not compliant to distribute that through the App Store, though there is some disagreement, and it has never been taken to court.
It is /definitely/ not compliant to distribute a proprietary app that links to an (L)GPL'd library through the App Store, since Apple only permits static linking.
GnuPG is an open source implementation of the OpenPGP standard. PGP is not in widespread use. GnuPG is not a good tool to add PGP support to other software.
That's a perfectly valid complaint. Your casual dismissal seems very wrong to me.
Depends on what industry/domain you work in. The reason PGP isn't more widely used is: It's expensive, it's complex to the typical "user" and businesses don't want to invest in real PKI even if they need it. (People are lazy and cheap...)
Add in the factor that most developers don't have the chops to figure out and implement nicer software based on the mess that is GPG. You have a few serious tools wrapping it used in ETL applications and ilk like Gpg4Win and the Bouncy Castle libraries.
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?
Thanks for the reference; Not using go, but it's still interesting.
Although, I realized it is unlikely I'll find a solution (golang or not) - because I actually need gpg to talk to my smart card.
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
It's also has a dual license.
set crypt_use_gpgme=yes
The author mentions GPGME in the article, but only to shrug it off as "too big". Given the fact that devices like the raspberry pi now run full Linux distributions, I'd say it's a weak argument.
Configuring GPG and Thunderbird is brain dead easy.
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.
I have never heard anyone say it was easy for mortals to use openssl in a safe and secure manner. Between openssl and gpg, gpg is hands down the better way for mortals or professional geeks to exchange information securely. For starters take a look at what is required to generate a key in gpg:
$ gpg --gen-key
That made my day.
Snort! How many clients/friends/coworkers have you had to explain PGP, GPG, public keys or just compressing a file with a password to?
For us semi-interested cypto/security aware geeks, it's not difficult. Easier than learning the details about git or picking up Erlang. But for the normal user/client/manager it's like speaking Latin or the understanding Alchemy economics in Skyrim. PKI/GPG is one of those things that falls outside of their give-a-shit enough to understand circle.
I've used GPG for years and love it. But even I have to jump through hoops that are not trivial to deal with -- I use GPG smartcards for a few applications, and while its great when it works, it often doesn't. I can't use it on OSX 10.8 right now, for example.