Re: [openpgp] saltpack on OpenPGP message format problems

["Neal H. Walfield" <[e-mail]>]

On Wed, 10 Feb 2016 10:29:44 +0100,
ianG wrote:
> 
> (we should probably fix these one day)
> 
> https://saltpack.org/pgp-message-format-problems
> 
> 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.
> 
> In contrast, NaCl encryption authenticates the sender 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.

For normal users, this is probably a bug.  But, for advanced users,
I'd consider this a feature.  Correspondingly, I think it makes sense
for signing+encryption to be the default for an OpenPGP implementation
and for mail clients to not offer an option to only encrypt.  But,
whatever the case, I don't think this should be removed.

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

Guilhem Moulin raised this point in December and suggested using
chuncked streams, which would preserve OpenPGP's streaming property:

  http://mailarchive.ietf.org/arch/msg/openpgp/YZP6dZMPzqlF4-9ISturX_Q_vQQ

I think it is worth fixing.  If not with Guilhem's solution, then with
something else.

> 3. Anonymous recipients aren't fully anonymous.
> 
> Even with the --hidden-recipient flag, RSA encryption leaks some
> information about the recipient's key.

Is the argument here that NaCL solves this problem?

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

This is a serious problem and I think the suggestion to use base-62
encoding is a good one.  Do others agree that this is worth solving?

Thanks,

:) Neal