a modern crypto messaging format

We know from re-implementing PGP's message format (RFC 4880) ourselves (here), it has a lot of issues. Some make life difficult for implementers, but others are problems for end users too:

1. PGP encryption doesn't reliably authenticate the sender.

PGP encrypted messages aren't authenticated by default. Even when you add signing, however, they're vulnerable to a "surreptitious forwarding attack". Normally when you read an encrypted message you know that you were the intended recipient, because the message is encrypted to your public key. When that message is also signed, you technically still know that it was encrypted for you, but you don't know whether the encrypter and the signer were the same person. If Alice signs-and-encrypts a message to Bob, Bob can decrypt the message and then reencrypt the same signed message for Charlie. The result is a message that appears to be from Alice to Charlie, even though that might not be how Alice intended it.

2. GnuPG will output data that doesn't verify.

If you run gpg --decrypt on a corrupt message, it will print the plaintext to stdout, and you'll only find out if the message is bad at the end, after you've streamed out unsigned data. Try it on this message signed by Jack's key:

Version: GnuPG v2


3. Anonymous recipients aren't fully anonymous.

Even with the --hidden-recipient flag, RSA encryption leaks some information about the recipient's key.

4. PGP ASCII armor isn't friendly to modern apps and phones.

One of many manglings

Almost all apps, email clients, chat clients, and web pages do post-processing on the text people post. PGP's whitespace pattern, use of hyphens and slashes, and header lines are not friendly. You shouldn't have to edit a message by hand before passing it off to your crypto program.

5. Lack of Constraints Can Be Dangerous

PGP's strategy of composable, nested streams is a headache to implement and allows attackers to craft messages that explode memory usage. There are workarounds, but the underlying problem is that the spec gives message crafters too much flexibility.

6. It's 2020 and PGP Still Hasn't Kicked SHA1 to the Curb

The spec requires key fingerprints to be output by SHA1. That hasn't bitten PGP yet but who knows. And for whatever reason, modern PGP clients will still accept signatures and keys that use SHA1, often with dire consequences.