Image of the glider from the Game of Life by John Conway
Skip to content

What's The Matter With PGP? has been making its way around crypto circles recently. Enough so, that I figured I would comment by posting a reply on my own blog.

This post is written by cryptographer Matthew D. Green. As a result, even though I've never heard of Dr. Green, when I read the post, I was expecting something of high caliber. After all, this isn't some random dude on the Internet blowing his horn. THIS IS A GENIUNE CRYPTOGRAPHER. Turns out, the post is complete junk. It's about as thoughtful and informative as the Nigerian 411 scam. Let's analyze the post, top-to-bottom.

First off, as a TL;DR, Dr. Green thinks PGP is Teh Fail. After reading the post, it almost seems to me that he just barely installed PGP on his desktop, couldn't figure most of it out, got confused by a great deal of the terminology (isn't he a cryptographer?), and threw his hands up in defeat. When you read it a 2nd time, you notice almost immediately that he is confusing a few things:

  • The OpenPGP specification.
  • The GnuPG implementation of the OpenPGP specification.
  • Mail client frontends to GnuPG.

Are they all Teh Fail, or just the OpenPGP specification? After reading it a few times, I'm convinced he is rolling up anything and everything to do with PGP, past, present, and future, as total failure. It's just unfortunate he can't set things straight between the OpenPGP specification, the GnuPG implementation, or a mail client.

Meh. Color me unimpressed, Dr. Green.

1. PGP Keys Suck
My favorite line out of his post is this:

"For historical reasons [PGP keys] tend to be large and contain lots of extraneous information, which it difficult to print them a business card or manually compare."

Yes, they are definitely large. But printing the entire key on a business card? Really?? I've been using GnuPG since 2004, and I've never heard of anyone wanting to even compare public asymmetric keys character-by-character, let alone print a full asymmetric key on a business card. This is what the SHA-1 fingerprint is for. It's been generally accepted that comparing keys using the 40-character hexadecimal string is sufficient enough to know that each person has the same key. Key signing parties are based on this principle. Fingerprints as a result have been printed on business cards. Example 1, example 2, example 3.

Regardless, asymmetric keys in general are nasty to deal with by hand. This isn't just a problem with GnuPG, but OpenSSH, OpenSSL, or any other front end implementation that uses public key cryptography. This shouldn't come as a surprise. This is why we have tools to work with them. Things like Gnu Privacy Assistant, KGPG, Enigmail, GnuPG, and others. There is nothing in the OpenPGP specification that defines how you should implement such a front end. As a result, this is not the fault of OpenPGP. If you don't like the way GnuPG handles transferring public keys from one destination to another, propose a patch?

Without taking a breath, he then complains that your request for a GnuPG key is over plaintext HTTP. Well, okay. Sure. HTTPS/HKPS would be optimal to transfer the key, and he rightfully identifies a bug with GnuPG that doesn't verify if the correct key was downloaded. But, again, this is not a problem with OpenPGP. OpenPGP does not define anything about infrastructure. These servers are poorly designed, with OpenPGP front ends like GnuPG full of bugs. Hardly a problem with OpenPGP. If you don't like the key server implementations, maybe submit a patch?

Then his rant turns to OpenPGP infrastructure, by bitching about public key servers (it actually seems like he's comparing everything to miniLock, and setting miniLock as the Gold Standard). His first gripe is getting keys via Twitter:

"If we must exchange things via Twitter, why not simply exchange keys?"

Really? Twitter? Do we want to rely on Twitter for getting public keys? We can't get them from an email, or in person, or from a website, or from a business card, or some other form of informational transfer? Just, Twitter?

Finally, he opens up ECC keys, with the following:

"Modern EC public keys are tiny."

Seems Dr. Green has some sort of obsession with ECC keys. Earlier he mentions that you can fit ECC keys on business cards. He continues comparing a lot of OpenPGP to ECC keys. I'll address that later.

2. PGP key management sucks
There really isn't much to say here. Every point I argued previously, in that OpenPGP provides no infrastructure, applies here. However, he does hit one topic which strikes me as odd: the Web of Trust. He says the following:

"Most OpenPGP implementations do a lousy job of presenting any of this data to their users anyway."

OpenPGP implementations should never define trust for the user. That should always be at the discretion of the user. OpenPGP implementations should only define accuracy, such as correctly decrypting an encrypted piece of text, or successfully verifying a digital signature, because that's all the OpenPGP specification defines. I decide whether or not to trust the data given to me by someone else. And, most of the tools I have dealt with properly work this way. A trust database exists on the computer, allowing me to say "I trust this key", "I don't trust this key", and so forth. I define how those trust relationships are built, and I can put them into the database, so OpenPGP front ends can notify to me whether or not I am dealing with trustworthy data. But notifications should be the extent of the Web of Trust in OpenPGP implementations. And just because I signed a key, doesn't necessarily mean I trust that data from that key owner, so the tool should never make that assumption.

3. No forward secrecy
Okay. I get it. People like perfect forward secrecy (PFS), even to the point of obsession. I'm not one of those people. I use OTR, and I implement PFS on SSL where appropriate, but I'm not going to lose any sleep over the fact that PFS isn't defined in OpenPGP. OpenPGP has its problems. PFS isn't one of them, for a couple of reasons.

First, email is generally looked upon as long-term communication. Most people want to read their email, not destroy it. Many use long-term archival to go back to email replies in a thread, or to look up purchase orders, or recall sensitive employee information. Email has value in multiple views. PFS just doesn't fit well here. If you want PFS in your communication, look at something where there is not high value in retrieving old communication, such as instant chat. Off-the-record (OTR) messaging works well here, but even then, it has it's problems. As someone who logs every chat message that comes in, I want to have the ability to decrypt old communication messages sent to me, for a number of reasons. OTR makes this impossible. OpenPGP makes this doable.

Second, GnuPG cryptographically signs encrypted data by default. Thus, if you were to use an OpenPGP implementation for end-to-end communication, all messages have been cryptographically signed. Enabling PFS is perpendicular to signed data. Prior messages should not only be un-decryptable, but they should also not identify who sent the message. Because OpenPGP implementations build everything around a Web of Trust, I find it difficult to see where PFS would fit at all.

However, this sentence down right scares me:

"If the NSA is your adversary just forget about PGP."

What does that mean? The NSA has beaten OpenPGP? I doubt it. Strongly doubt it, actually. So much so, I'm really beginning to wonder about Dr. Green's competence as a cryptographer. Dude, look at the specification, and tell me the NSA has beaten every cryptographic cipher and hash in that RFC. I don't buy into the conspiracy theories that the NSA has some super-duper-uber-mega-cracking-datacenter, and AES-256 is child's play to the NSA. I trust the mathematics, and I trust academia. Maybe the NSA has their own microprocessor manufacturing plant? That has outpaced Intel? Yeah, not buying it.

However, maybe Dr. Green means to say that if you're targeted by the NSA, then before you even use your OpenPGP implementation to encrypt some communication, the NSA has a copy. But then, how is this a problem of OpenPGP and its implementations?

As a cryptographer, to wave your hand like a Jedi, claiming thet PGP is worthless in front of the NSA is frightening. Not because there might be some truth to it (there isn't), but because that's just amateur FUD slinging. For someone with a Ph.D in the field, I would expect better.

4. The OpenPGP format and defaults suck
Hahahahahahahahahahahah. Uh, no. Not even close. I literally laughed out loud when I read that section. So much so, I showed a couple of mathematicians and amateur cryptographers, and we had a good time.

Chapter 9 of RFC 4880 (the OpenPGP RFC) defines the following constants:

9.1. Public-Key Algorithms

ID Algorithm
-- ---------
1 - RSA (Encrypt or Sign) [HAC]
2 - RSA Encrypt-Only [HAC]
3 - RSA Sign-Only [HAC]
16 - Elgamal (Encrypt-Only) [ELGAMAL] [HAC]
17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA
20 - Reserved (formerly Elgamal Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm

Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys (1). RSA
Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be
generated, but may be interpreted. See Section 13.5. See Section
13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or
Sign (20), and X9.42 (21). Implementations MAY implement any other

9.2. Symmetric-Key Algorithms

ID Algorithm
-- ---------
0 - Plaintext or unencrypted data
2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
168 bit key derived from 192)
3 - CAST5 (128 bit key, as per [RFC2144])
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - Reserved
6 - Reserved
7 - AES with 128-bit key [AES]
8 - AES with 192-bit key
9 - AES with 256-bit key
10 - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm

Implementations MUST implement TripleDES. Implementations SHOULD
implement AES-128 and CAST5. Implementations that interoperate with
PGP 2.6 or earlier need to support IDEA, as that is the only
symmetric cipher those versions use. Implementations MAY implement
any other algorithm.

9.3. Compression Algorithms

ID Algorithm
-- ---------
0 - Uncompressed
1 - ZIP [RFC1951]
2 - ZLIB [RFC1950]
3 - BZip2 [BZ2]
100 to 110 - Private/Experimental algorithm

Implementations MUST implement uncompressed data. Implementations
SHOULD implement ZIP. Implementations MAY implement any other

9.4. Hash Algorithms

ID Algorithm Text Name
-- --------- ---------
1 - MD5 [HAC] "MD5"
2 - SHA-1 [FIPS180] "SHA1"
3 - RIPE-MD/160 [HAC] "RIPEMD160"
4 - Reserved
5 - Reserved
6 - Reserved
7 - Reserved
8 - SHA256 [FIPS180] "SHA256"
9 - SHA384 [FIPS180] "SHA384"
10 - SHA512 [FIPS180] "SHA512"
11 - SHA224 [FIPS180] "SHA224"
100 to 110 - Private/Experimental algorithm

Implementations MUST implement SHA-1. Implementations MAY implement
other algorithms. MD5 is deprecated.

Please identify what is wrong with this specification. GnuPG implements IDEA, CAST5, 3DES, AES, AES-192, and AES-256 as ciphers, and RIPEMD-160, SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 as cryptographic hashes. What are wrong with these defaults? Please, enlighten us Dr. Green.

However, Dr. Green is mixing what the OpenPGP specification requires and what implementations use. The RFC exists as a core minimum set of standards, defining what is required to use as a base, with things optional and deprecated. However, GnuPG (as well as PGP) have both gone well beyond the defaults that the RFC requires.

But then there's this little gem:

"Elliptic curve crypto is (still!) barely supported."

He's back at ECC. Of course, this shouldn't come as much of a surprise, but there is a good reason most academic and open source cryptographers have steered clear of ECC- software patents:

According to Bruce Schneier as of May 31, 2007, "Certicom certainly can claim ownership of ECC. The algorithm was developed and patented by the company's founders, and the patents are well written and strong. I don't like it, but they can claim ownership."

Dr. Thomas Pornin (one cryptographer on Stack Exchange I have great respect for) answers the ECC patents this way:

"To my knowledge (but I am not entitled, in any way, to give law-related advice), parts of ECC cryptography which may still be patented are:

  • implementation of curves over binary fields using normal bases;
  • point compression;
  • acceleration of Koblitz curves using the Frobenius endomorphism;
  • various optimization tricks on dedicated hardware architectures (FPGA, ASIC)."

However, there is finally an RFC for ECC in OpenPGP. It defines three curves, which are also already standardized by NIST (pdf)- Curve P-256, Curve P-384, and Curve P-521. This document was standardized only two years ago, June 2012. Unfortunately, these three curves do not meet the "safe curves" definition as defined by Dr. Daniel J. Bernstien ("djb").

GnuPG will likely use EdDSA and Ed25519 as default for signatures (the same algorithms supported by OpenSSH actually). Werner did implement Brainpool P256r1, P384r1, and P512r1, even though it is not defined in the RFC.

5. Terrible mail client implementations
Again, mixing the OpenPGP standard, which does nothing to define how an MUA should behave, with a front end to a specific OpenPGP implementation. Regardless, there are some hidden gems in this section.

First, his claim that we're storing the passphrase to the private key in memory:

"[Mail clients] demand you encrypt your key with a passphrase, but routinely bug you to enter that passphrase in order to sign outgoing mail -- exposing your decryption keys in memory even when you're not reading secure email."

Hahahahahaha. Oh, boy. I guess we haven't heard of "GnuPG Agent"? Yeah, there's this thing that exists setting up a "token" based system. If you can successfully decrypt your private key, GnuPG will setup a token which is cached in RAM. Then, the MUA just needs to check if such a token exists. If so, it can use the full features of decryption and signing, without ever asking the user for the passphrase.

Regardless, if an attacker has access to your RAM to read it's contents, then you have bigger fish to fry, and there is nothing on the OpenPGP specification to help you.

Now this little gem:

"Most of these problems stem from the fact that PGP was designed to retain compatibility with standard (non-encrypted) email. If there's one lesson from the past ten years, it's that people are comfortable moving past email."

Really, I'm fairly confident that I don't need to say much here, but I'll just end this section with my own personal thought:

"If there's one lesson from the past 50 years, it's that people are not comfortable moving past email."

What's cute, is his examples to vendor controlled messaging systems provided by Apple, Facebook, and WhatsApp as a way to do secure communication. All proprietary, all vendor controlled lockin, all reliant on 3rd-party infrastructures, all client-server encrypted/decrypted, and not end-to-end, which OpenPGP is not. OpenPGP is end-to-end encryption, decentralized, and ad hoc. More importantly, the largest implementation (GnuPG) is Free and Open Source Software.

6. So what should we be doing?
Well for one, not listening to Dr. Green. OpenPGP has legitimate concerns, no doubt. But they aren't what are described in the article. He followed a white rabbit down a hole, when he should have just been studying the specification, and identifying it's real problems.

For example, if using OpenPGP in email, all of the email headers remain in plaintext. Only the body is encrypted. This metadata can reveal a great deal of information, such as the sender and recipient, the SMTP servers used in the exchange, the subject content, additional recipients on the carbon copy, etc.

Further, because OpenPGP encrypts data in packets, "header packets" exist in every OpenPGP encrypted file. These header packets can also reveal a great deal of information, such as who encrypted the data, who the recipient of the encrypted data is for, when the encrypted data was created, and other things.

In other words, one problem with OpenPGP is plausible deniability. If you want your encrypted data to be indistinguishable from true random, you're going to fail miserably using OpenPGP. OpenPGP concerns itself with message confidentiality and integrity- deniability just isn't in its scope.

For me, throwing away PGP, because of a number of misguided personal opinions, seems like a Big Mistake. GnuPG has been in development since 1999. OpenPGP itself has undergone revisions, improving the specification. PGP, which OpenPGP built itself upon, is even older, entering the arena at 1991. Throwing 23 years of development, bug fixing, and revisions out the window, just because one troubled cryptographer doesn't like it, seems to be akin to the very tardy, and incomplete Netscape 6.0 release.

{ 10 } Comments

  1. rootbsd | August 18, 2014 at 2:08 am | Permalink

    wow. you nailed it 🙂 very interesting post.

  2. Mircea Popescu | August 18, 2014 at 2:47 am | Permalink

    Turns out, the post is complete junk. It's about as thoughtful and informative as the Nigerian 411 scam. Let's analyze the post, top-to-bottom.

    Pretty much the conclusion reached on #bitcoin-assets too.

  3. Mircea Popescu | August 18, 2014 at 2:49 am | Permalink

    Ps. If you care, add one more to your collection of keys printed on business cards.

  4. Frakturfreund | August 24, 2014 at 8:35 pm | Permalink

    There are some corner cases in which tiny keys are nice to have. For example, there's a software called Paperkey to print your private OpenGPG key on a paper for long-time backup. It can also strip it to the absolute minimal amount of bytes, so that it can be more easily restored (manually typed back into the computer).

  5. Gerry | August 25, 2014 at 4:58 pm | Permalink

    Adding to the "terrible mail client implementations" accusations:

    KMail of the KDE project had simple PGP integration over 10 years ago when I was testing Beta versions of KDE 2.
    The only hassle was entering the passphrase, but that could be stored in RAM giving you basically a whole workday of encrypted and signed mail without additional effort.
    Notwithstanding the one-off effort to get the recipients public key and assigning it to his addressbook entry.

    @ Frakturfreund

    I remember joyful days in my youth when I was typing binary listings of little tools and games for the C64 which where published in 64'er magazine.
    Long lines of hexadeximal digits with check digits for each line.
    Something like the program used for typing the listings would make typing a full length PGP key from paper boring but essentially hassle free.

  6. ketzu | August 26, 2014 at 7:25 am | Permalink

    I dont like your post very much, especially because you are a jerk about your response.

    But this is what I thought while reading it:
    3. Yes the importance of PFS is probably personal preference, but having PFS does not stop a legimate archiver. But some people want to be able to delete mail and be sure not to leave a copy on one of the servers it went through that can be of much use.
    Also PFS and non repudiation/signing are not mutually exclusive.

    4. So the defaults are Elgamal+DSA, Triple DES, SHA-1 and uncompressed, since they are the only "must have"s?
    They are not broken by now (as far as I know) but for some of them it's questionable for how long. I think Mr. Greens intention was that "historic" algorithms should be marked deprecated and more modern algorithms should be made the default choice (must have) in time.

    1.,2. & 5. Usability is a big problem for user acceptance. Without user acceptance a system will remain a niche product. The examples of messaging systems weren't, as I understood, for secure systems, but to show people actually do use different systems from email. How can you be confident on this for a system that got popular 20 years ago? Especially if the follow up might feel just like e-mail but has advantages? Or provide a transitional translation to regular e-mail unless both parties use the new system?

    Also "no one ever wanted to do this" is not a good argument at all. Making it sufficient to compare hashes probably stems from the size of the keys! Also you ridicule the idea of printing your key on a business card. Why? Is it a bad idea? Your e-mail is on it, why not provide the key? You could still provide an online service to receive public keys and compare or not. Every public crypto system ever urges it's user to make sure she got the genuine key through another channel or security might be broken, but actually wanting to do it is a stupid idea?

    I have never heard of gnupg-agent, maybe Mr. Green hasn't, too. Is this a problem? Yes. If there is a perfect security addon most users don't know about or if it's so useful, wha have it as an addon at all?

    This leads to 6.

    On the one hand you think people are not interested in moving from e-mail, but are happily running after openpgp and additional software which are complicated to use for ordinary users. Mr. Green does not suggest we thow away OpenPGP instantly, but we start working on an alternative system. You mentioned a few problems yourself and some can not or wont be tackled by OpenPGP because it is not designed to do it or cannot be designed to do it, because it would break e-mail.

    Getting another 23 years of development and bug fixing wont get easier if we dont start soon.

  7. Mircea Popescu | August 27, 2014 at 1:09 pm | Permalink

    1.,2. & 5. Usability is a big problem for user acceptance. Without user acceptance a system will remain a niche product.

    This is not a cogent consideration. Everything good in this world is and should forever remain a niche product. The mass can go take a long walk off a short pier.

    How can you be confident on this for a system that got popular 20 years ago?

    There are two types of idiots in this world. One says, "this is old and therefore bad", the other "this is new and therefore better". You can be sure of stuff 20 years old. You can't bew sure, and if you have any sense will not use, the currently released crapolade. Let it get to be 20 years first, then maybe consider it.

    Also "no one ever wanted to do this" is not a good argument at all.

    You are too stupid to participate in this discussion. Shut up and go to school for a coupla decades.

  8. Peter | September 1, 2014 at 9:50 am | Permalink

    You made my day. Green complained about usability, but not about security issues.
    See also my blog entry here

  9. Vess | September 3, 2014 at 6:07 am | Permalink

    I fully agree with everything you've written about Dr. Green's rant.

    What I disagree with are only some things implied indirectly by your article. You seem to be a big fan of GnuPG and seem to imply that it is basically interchangeable with PGP; like a "modern version of PGP". It is anything but.

    GnuPG is a buggy, incompatible piece of crap, developed by self-centered morons. It is made by geeks for geeks. Especially in the area of signing, parts of it simply do not work.

    Try, for instance, to binary sign a file in a way that is verifiable by PGP 2.x. (Detached signatures and clearsigned texts work fine.)

    gpg --sign --rfc1991 --armor --local-user YourUserID --output file.asc file.bin

    PGP will be unable to verify the signature. Depending on the version of PGP used, it will say nothing, will complain about missing signature, or will ask you about the file containing the detached signature.

    Worse, even GnuPG itself will not be able to process its own output from the above! Now, how stupid is that?! It will complain that the file contains a PGP 2.x signature and cannot be processed, which is a lie, because GnuPG can verify genuine PGP 2.x-generated signatures just fine.

    The reason for this idiocy is that, despite the use of the --rfc1991 option, GnuPG is NOT RFC-1991 compliant when generating signatures. The RFC-1991 unambiguously specifies that the signature packet must precede the literal packet, while GnuPG outputs them in the reverse order. That's OpenPGP behavior, not RFC-1991 behavior.

    Additionally, and probably for the same reason, GnuPGP lacks the ability to seamlessly sign-and-encrypt a file in a way which is understandable by PGP 2.x. It *can* be done but requires the use of 5 (five!) separate commands, four of which are GnuPG invocations and one is a copying command for concatenating two files.

    Furthermore, PGP 2.x can be compiled on just about anything that has a C compiler (and it will run correctly there). I was unable to compile GnuPG on a Windows machine. I was told to use Linux and cross-compile it there for Windows (which is the most idiotic advice I've ever heard) - but it failed to compile on Ubuntu Linux I've set up in a VirtualBox, either.

    Basically, GnuPG is a buggy, incompatible, unusable piece of crap and its developers have refused to fix the bugs mentioned above (which have been reported to them). I'm sticking with PGP.

  10. Adrian Cohea | September 20, 2014 at 1:17 pm | Permalink

    Dr. Green is a very respected cryptographer, and just because we might be hurt or offended as GnuPG users doesn't mean we have to disparage him professionally. I'll agree that the "if the NSA is your adversary, forget about PGP" comment was out of line and way over the top.

    Honestly, I think part of Dr. Green's problem here is that he simply doesn't like the properties supplied by the OpenPGP standard and prefers OTR for its security properties. I find OTR's security properties completely unacceptable. Deniable authentication is a non-starter for me, because I don't want people I communicate with to have an ability to repudiate. However, I understand that there are legitimate threat models in which OTR's properties are the ONLY acceptable properties. (For example, a journalist wants to talk to a whistleblower, or a human rights activist wants to find a contact to send documentation of human rights abuses.) The difference is I don't go around trashing OTR as a total failure even though I hate its security properties. I respect it for its uses, but I'm completely uninterested in its use case.

    One thing I wish is that this article had made more positive mention of elliptic curve cryptography. Werner and the GnuPG team are doing a good job of implementing ECC in GnuPG. There's more than just a new RFC. I have a working Brainpool P-512r1 ECDSA/EDCH keypair. All of this will be fully supported in GnuPG 2.1. Yes, it's still in beta, but it's coming along quite well, as I can see from the commit mailing list.

Post a Comment

Your email is never published nor shared.