saltpack
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 authenticate the sender.

There's no way to verify who a PGP message is from unless it's signed. That means that as a sender, you can't authenticate yourself without giving up repudiability. Partly because of this, authentication is off by default.

But it's actually worse than that. 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, technically you still know that it was encrypted for you, but you don't know whether the encrypter and the signer were the same person. In a "surreptitious forwarding" attack, Alice signs-then-encrypts a message to Bob, Bob decrypts the message, and then Bob reencrypts the same signature for Charlie. The result is a message that appears to be from Alice to Charlie, but isn't.

In contrast, NaCl encryption authenticates both the sender and the recipient in a repudiable way. That makes it easy for us to enable authentication by default. It also means that we don't need special support for a "signed and encrypted" mode, because very few applications actually want that.

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:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

kA0DAAIBcYdraK1ILTIBy5liAFaqa7BKb2huIEphY29iIEppbmdsZWhlaW1lciBT
Y2htaWR0LApIaXMgbmFtZSBpcyBteSBuYW1lIHRvby4KV2hlbmV2ZXIgd2UgZ28g
b3V0LApUaGUgcGVvcGxlIGFsd2F5cyBzaG91dCwKVGhlcmUgZ29lcyBBIE1BTiBJ
TiBUSEUgTUlERExFIE9IIFNISUlJMTF0IQqJARwEAAECAAYFAlaqa7AACgkQcYdr
aK1ILTK6Ewf9GIIzBmtGuNeJXUGAoDbG5mmVDyMwpu3i72OwOfoSo+4GI6mT/FuV
PKh7HCKwglmTuO2oazg0sUnoktjmHxdNQuJZ+6ii/5xXb80XEHFECFDClrjwbkeE
+3irJDrpnmuQzRyJVOYh+fr7dxrlN7pgMdjlkbAgWnATZ+k1zf8z40p8SANNpXHt
9yie6nuzKUd1LUujPa4sz6BfNW0Clcp3c0XFeU2je//4TcZ+4/Ql2B1/MdzqF4+G
TPh+B1L8k9F9TNgyh9lXyez90oRLEvw3+3o9+CvMvQb6Gb8aR+eW/rE+wabdiwSY
qfLaI0VHvwNCa1NV/5MmX6UKUzNV2c4vcAo=
=uIW7
-----END PGP MESSAGE-----

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.