

GnuPG - 16 Years of protecting privacy - e1ven
http://blog.gnupg.org/20131220-gnupg-turned-0x10.html

======
tptacek
So many people seem enamored of the idea of building software to protect users
from NSA, and respond by designing new cryptosystems. These efforts invariably
fail, because crypto is very hard, and professional crypto requires 10x
verification (particularly at the design stage) as it does implementation.

It baffles me that nobody has instead picked up the challenge of taking the
PGP/GPG cryptosystem and making it more usable. That seems like an incredibly
valuable project that also makes great use of the skills of the sorts of
people that tend to want to work on privacy software.

Paradoxically, the more you know about crypto, the less inclined you usually
are to build new crypto.

~~~
e1ven
I've been working on using GPG behind-the-scenes, so I can speak to a few
reasons why it might not be used more frequently.

1) GPG is -terrible- to use as a library.

There are a lot of wrappers for various languages. Almost most all of them
call the gpg executable, and scrape it's input. This is crazy-town loony-
toons.

In theory, gpgme is supposed to be the solution.. But gpgme ends up calling
the binary itself in many cases!

2) GPG assumes you want to use the whole ecosystem.

GPG is sort of a mega-framework. It assumes you want to do everything the GPG
way - Use gpg subkeys, keyservers, WOT, Import keys to a central keychain,
etc.

I've been able to go through with options flags and disable things I don't
want, but it's all opt-out, not opt-in.

3) Because of 1 and 2, you can't run GPG entirely in memory. It writes a lot
of files to the filesystem.. I've been bypassing this by running in ramdisks
with ephemeral directories, but it's a PITA.

4) 2.1 has been in the works.. FOREVER.

The first betas of gpg 2.1 were in 2010.. I understand they want to get this
right, but that's a really really really log dev-cycle. I donated to the
crowdfunding, and I hope it helps get gpg out sooner.

GPG 2.1 is the first stable gpg release that includes ECC support
(specifically, DJB's 25519). This is a really really big feature, that a lot
of people have been waiting for.

In any event, I like GPG, and I'm using GPG because it's been hardened, and
I'm not smart enough to do my own crypto.

But GPG doesn't make itself easy to integrate.

~~~
nwalfield
Unfortunately, there are a couple of misunderstandings here.

It is true that libraries call the gpg binary. This is a feature, not a bug.
This architecture makes bugs in the applications less likely to affect the gpg
code / data. For instance, it's a lot harder to dump the variable containing
the secret key if it is in another process.

The wrappers don't scrape the output. There is a well-defined protocol for
interacting with the binary.

~~~
e1ven
Cool. Maybe our definitions of scrape are what's causing the disagreement.
Sorry about that!

When I look at the code that calls the GPG binary, in the python lb at
[https://code.google.com/p/python-gnupg/](https://code.google.com/p/python-
gnupg/) it seems to be reading/writing stdout/stdin. It doesn't appear to be
using a socket connection, or any other non-typical way of accessing it.

return Popen(cmd, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE) def
_read_response(self, stream, result): Internal method: reads all the stderr
output from GPG, taking notice # only of lines that begin with the magic
[GNUPG:] prefix. etc

In trying to gpg in my apps, having a library which lets me generate a pgp key
in memory, read it in to a string, write it out to a string, and sign/encrypt
strings or binaries would be optimal.

I don't want to have to worry about where the .gnupg home directory is being
created.. I don't want any files stored. I don't want to access any
keyservers, I'm doing all the key verification through other channels.

Essentially, I'd like to be able to use GPG more like NaCL/Libsodium.

~~~
mkesper
Nobody should ever use shell=True. A saner approach would be to build upon
gpgme.

------
grandinj
Except that the tool itself is so painful to use, and has such a shallow
integration with things like email clients, that using it requires a
considerable degree of self-discipline.

I think I installed it once, and then when my machine required rebuilding, I
just couldn't bring myself to install it again.

I wish it weren't so, but a new website is not something that is going to
speed the adoption of GnuPG.

~~~
technomancy
I started using GPG seriously once the "easypg" integration landed in Emacs
23. When you open a .gpg file it prompts for your passphrase and decrypts
transparently, and when saving a new .gpg file it prompts you with a list from
which you can select recipients to encrypt to.

The integration with Emacs mail clients is fantastic too; just M-x mml-secure-
sign or M-x mml-secure-encrypt when composing, and incoming messages with
signatures are typically checked for you.

This totally changed the way I used GPG. (from "not at all" to "every day")

~~~
stinkytaco
I'm working through the irony of your finding GPG easier to use once it landed
in _emacs_. I mean... Emacs for God's sake.

In all honesty, however, part of the "difficulty" of GPG is really by design.
You need to be deliberate about signing and encrypting because security should
be a careful and deliberate act. If you're hoping for the program to take care
of it transparently, you're probably not being safe enough. At least Emacs
requires you to go through an explicit process. As you have to do with
_everything_ in Emacs.

~~~
velis_vel
> You need to be deliberate about signing and encrypting because security
> should be a careful and deliberate act.

Why? You don't have to be 'deliberate' about encrypting when you're using SSH
or HTTPS.

~~~
stinkytaco
True, but we're putting a lot of trust in third parties in that situation, no?
HTTPS requires us to say "sure Verisign [or insert authority here], I believe
you." If I'm doing that, why not just trust Google? Why use email encryption
at all?

SSH is more in our control, but it's still trusting a third party (a server)
and it still requires a deliberate act to set up and use (unlike HTTPS).

------
nwalfield
This blog post is partially about the crowd funding campaign, but the author
didn't include a link to the campaign!

[http://goteo.org/project/gnupg-new-website-and-
infrastructur...](http://goteo.org/project/gnupg-new-website-and-
infrastructure/home)

------
miga
2^2^2 years protecting privacy, that is!

~~~
iso-8859-1
From now on it will never again not matter if you evaluate that expression
from left to right or right to left :)

------
Trufa
For a more readable format:
[https://www.readability.com/articles/jzsno986](https://www.readability.com/articles/jzsno986)

~~~
vezzy-fnord
I don't see any discernible difference.

------
codex
Changes to Gmail made by a couple of engineers would so more to protect
privacy than GNU ever could.

~~~
technomancy
Right, as if Gmail would even exist without GNU.

~~~
clarry
What does Gmail require GNU for?

~~~
dredmorbius
Assuming sincerity: much of the technical stack is based on GNU tools,
projects, libraries, etc.

