The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools


pgpfan:tpp

This is an old revision of the document!


The PGP Problem: A Critique

The article can be found here:

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. The other requirement here is efficiency which a packet format has been shown to support in this case.

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.

… which also follow this deranged format.

I will acknowledge that this is a rant. So it primarily expresses the feelings of the writer. So I will mostly address the parts that bring up interesting points.

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 first. 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.

So OpenPGP invented the MDC system: …

The MDC is a simple check of message integrity mostly intended to support the rarely used PGP feature of unsigned messages. By implying that it is some sort of authentication system the writer has created a straw man.

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.

Further, a rather large fraction of PGP users make use of keyservers, …

They do? A PGP keyserver links an email address 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. If they get your private key then they almost 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.

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.

Modern protocols like TLS 1.3 are jettisoning backwards compatibility with things like RSA, not adding it.

Only for one specific type of key exchange. TLS 1.3 otherwise supports RSA as per normal.

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 and it had nothing to do with “releasing unauthenticated plaintext to callers”.

Encrypting Email Don’t.

Are we being trolled here? Is the writer really asking us to give up on the idea of asynchronous communications entirely?

PGP FAN index

pgpfan/tpp.1591836040.txt.gz · Last modified: 2020/06/11 00:40 by b.walzer