This is an old revision of the document!
The PGP Problem: A Critique
The anti-PGP rant in question can be found here:
I only use Signal Messenger as a counter example in the following because the author of the rant uses it as an example of something that they think could be used as a replacement for encrypted email. I currently consider Signal Messenger one of the best in its class (2020).
For reasons none of us here in the future understand, PGP has a packet-based structure.
That is because a long term standard must be extensible. Thus the fields can not be fixed and it must be possible to add new types.
There are at least 8 different ways of encoding the length of a packet, depending on whether you’re using “new” or “old” format packets.
This is true in a narrow technical sense but is misleading. Both old and new formats are variable length. The old format has a 2 bit field to indicate the number of bytes used for length. The new format uses a simple length extension based on the bit patterns of the first byte. This is a common technique. UTF-8 does the same sort of thing but no one is claiming that there are 6 (4) different UTF-8 representations.
The “new format” packets have variable-length lengths, like BER (try to write a PGP implementation and you may wish for the sweet release of ASN.1).
The OpenPGP standard provides explicit cases for each extent of the length header (there are only 4). All you have to do is directly transcribe these cases into a case statement and you are done. There is no real thinking required. The standard even goes further and provides examples.
Since this is from the public key section of the PGP published standard it might be interesting to compare with the same sort of thing from the Signal Protocol … and we immediately discover that there is no such thing. No published standard and no user access to Signal identity information outside the program.
The most recent keyserver attack happened because GnuPG accidentally went quadratic in parsing keys, which also follow this deranged format.
It was actually about adding keys and it was not accidental. GnuPG undoubtedly did things the way they did for simplicity. That's a common theme in the PGP ecosystem.
The actual system doesn’t get simpler.
Compared to what working public key based public key system? OpenPGP as a protocol is relatively simple.
If you’re lucky, your local GnuPG defaults to 2048-bit RSA, …
Which is wild overkill, but I don't think that the writer meant to imply that. RSA with 2048 bit keys is a perfectly reasonable and conservative default.
… the 64-bit-block CAST5 cipher in CFB, …
Here are the symmetrical ciphers GnuPG version 2.2.12 accepts ordered from highest preference to lowest preference:
Cipher: AES256, AES192, AES, 3DES
CAST5 isn't even in the list, much less a default of some sort.
PGP begs users to keep a practically-forever root key tied to their identity.
Most people prefer to keep their identity indefinitely. That is why, say, the Signal protocol also has a “practically-forever root key tied to their identity”. It is inherent to the problem.
The PGP cheering section will immediately reply “that’s why you keep keys on a Yubikey”.
That particular cheering section might eventually get around to that, but they first would mention the use of subkeys. By default GnuPG generates a key for signing (identity) and a separate subkey for encryption. So in practice you are no worse off than with, say, Signal just as long as you are willing and able to mark an encryption key as compromised before generating a new one.
Subkeys are a fairly fundamental PGP concept…
…they needed to authenticate ciphertext, and that PGP’s signatures weren’t accomplishing that.
PGP's signatures are cryptographically strong and are indeed intended to both prove that a particular entity sent a message and that message was delivered as sent. They work very well in practice and are normally used.
PGP does a mediocre job of signing things, a relatively poor job of encrypting them with passwords, and a pretty bad job of encrypting them with public keys. PGP is not an especially good way to securely transfer a file. It’s a clunky way to sign packages. It’s not great at protecting backups. It’s a downright dangerous way to converse in secure messages.
I don't know what to make of this. These are all things that PGP does well in a simple straightforward way. Perhaps this is meant as an expression of the authors feelings…
Secure messaging wants crypto that is different from secure backups or package signing.
I can't really say anything here because there is nothing to support the contention. From here on I will skip over such bland statements with no context.
We’ve learned a lot since Steve Urkel graced the airwaves during ABC’s TGIF…
Then the author goes on for a while about how all the PGP things are bad because they are old. This seems to be a key theme here. Old is bad. New is better.
We’ve understood authenticated encryption for 2 decades, and PGP is old enough to buy me drinks; enough excuses.
But apparently the author does not understand why authenticated encryption is not used or even required for the things that PGP is normally used for. Attacking the proceeding contention would normally be required before bringing up the authenticated encryption issue. This suggests that the author has no real idea of how PGP works, but still thought it was a good idea to create a rant about it.
There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again.
There have been several encrypted messaging usability studies conducted over the years. They tend to use PGP rather than the encrypted messenger of the week for obvious reasons. They are usability studies. They are deliberately designed to be as difficult as possible (you hide all the documentation) in order to get results. If you wanted to compare the usability of a particular PGP supporting client to other clients you would have to make a different study.
The PGP MDC can be stripped off messages –– it was encoded in such a way that you can simply chop off the last 22 bytes of the ciphertext to do that.
This is true. It just means that a missing MDC is considered invalid.
To retain backwards compatibility with insecure older messages, PGP introduced a new packet type to signal that the MDC needs to be validated; if you use the wrong type, the MDC doesn’t get checked.
That's just a different way to say that MDCs can be stripped.
Even if you do, the new SEIP packet format is close enough to the insecure SE format that you can potentially trick readers into downgrading; …
… and that is the third time the fact that MDCs can be stripped is mentioned, in the same paragraph. This rant tends to repeat the same point over and over again, but this is a bit exceptional. Quite excessive when talking about a feature that is not normally used in PGP.
The author mentions that the MDC can be stripped in another portion of the rant for a total of four times.
Trevor Perrin worked the SEIP out to 16 whole bits of security.
If you read the linked mailing list thread you will discover that this statement is quite misleading. Trevor Perrin was discussing an attack on MDC which at one point required guessing with only a one in 2^16 (65536) chance of getting the guess right. In the end he concluded "There's a lot of caveats to this attack, so it's probably not anything to seriously worry about:".
And, finally, even if everything goes right, the reference PGP implementation will (wait for it) release unauthenticated plaintext to callers, even if the MDC doesn’t match.
There is no such “reference PGP implementation”. OpenPGP takes the form of an IETF published standard.
Ordinary people will trust anything that looks like a PGP key no matter where it came from …
In the same way that “ordinary people” will never bother to check their key fingerprints when using other systems. They will also ignore warnings that those fingerprints have changed. The problem is logically the same and PGP is no worse off here. PGP in a sense is better here in that it forces the user to comprehend the existence of a key in a way where it is intuitively obvious that it is important to know where that key came from.
Further, a rather large fraction of PGP users make use of keyservers, …
They do? A PGP keyserver links an email address (and a key fingerprint) to a PGP identity. That identity might not be linked to a physical identity at all. If you did not want this linkage then you would have no reason to use a keyserver.
Forward secrecy means that if you lose your key to an attacker today, they still can’t go back and read yesterday’s messages; …
Unless those messages are archived, which is normally the case with email and tends to be the default on other systems (e.g. Signal Messenger). If they get your private key then they pretty much for sure get your archived messages. Very few people are willing to go without a message archive so forward secrecy is unlikely to help in most cases.
In modern cryptography engineering, we assume our adversary is recording everything, into infinite storage. PGP’s claimed adversaries include world governments, many of whom are certainly doing exactly that.
Almost all email in transit (>90%) is protected by SMTP STARTTLS these days. So in practice those world governments don't have access to your PGP messages recorded off the wire any more.
If we’ve learned 3 important things about cryptography design in the last 20 years, at least 2 of them are that negotiation and compatibility are evil.
Then it is fortunate that PGP does not do negotiation. It can't. PGP supports asynchronous store and forward applications. It works over a one way channel. Your cipher, digest, and compression preferences come along with your public key They are signed and so are protected by the base cryptographic system. An adversary would have to break the cryptography to modify your preferences.
I do not agree that compatibility is a bad thing. PGP is actually a good example of how to deal with backwards compatibility in a good way.
The 2018 Efail vulnerability was a result of it releasing unauthenticated plaintext to callers.
Sort of a weird example. EFAIL turned out to be a kind of a media hoax against PGP and it had nothing to do with “releasing unauthenticated plaintext to callers”.
Encrypting Email
Don’t.
Comment not required here.