Subject: [openpgp] saltpack on OpenPGP message format problems

From: ianG <[email-masked]>
Date: Wed, 10 Feb 2016 09:29:44 +0000

(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 
<https://tools.ietf.org/html/rfc4880>) ourselves (here 
<https://keybase.io/kbpgp>), 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.

        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 byJack's key <https://keybase.io/oconnor663/key.asc>:

|-----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 encryptionleaks some 
information about the recipient's key 
<http://security.stackexchange.com/a/22705/36852>.

        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 thatexplode memory usage 
<https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4402>. There 
are workarounds, but the underlying problem is that the spec gives 
message crafters too much flexibility.

---

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 10 Feb 2016 11:46:26 +0100

On Wed, 10 Feb 2016 10:29:44 +0100,
ianG wrote:
> 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:
> 

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.

> If you run gpg --decrypt on a corrupt message, it will print the
> 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
> 
> 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.

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

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

---

From: Stephen Paul Weber <[email-masked]>
Date: Wed, 10 Feb 2016 11:06:41 -0500

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

Couldn't we just say "PGP is binary, encode however you like"?  In email we 
have transport encodings, and so do most other reasonable places.  The only 
real use for ASCII armor anymore is in "clearsign" context when posting 
a plain text file that contains the signature, etc.

---

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 10 Feb 2016 20:54:19 +0100

On Wed, 10 Feb 2016 17:06:41 +0100,
Stephen Paul Weber wrote:
> Couldn't we just say "PGP is binary, encode however you like"?  In
> email we have transport encodings, and so do most other reasonable
> places.  The only real use for ASCII armor anymore is in "clearsign"
> context when posting a plain text file that contains the signature,
> etc.

I disagree.  If you are being really paranoid, then you don't want to
use OpenPGP from an email client.  Instead, you write your message
using something like vi, encrypt it from the command line, and then
copy and paste the result into your mail client.  Then you are certain
that your mail was encrypted and that you don't accidentally send an
unencrypted draft, etc.

:) Neal

---

From: Stephen Paul Weber <[email-masked]>
Date: Wed, 10 Feb 2016 16:31:08 -0500

>that your mail was encrypted and that you don't accidentally send an

Sure, but then just attach the binary file instead of cut-pasting some ASCII 
stuff.  Same effect.

---

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 10 Feb 2016 23:02:19 +0100

On Wed, 10 Feb 2016 22:31:08 +0100,
Stephen Paul Weber wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> Sure, but then just attach the binary file instead of cut-pasting some
> ASCII stuff.  Same effect.

I still think the copy and paste work flow will lead to less mistakes.
But, of course, if you send the wrong encrypted file to someone, the
she won't be able to read it.

:) Neal

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 11 Feb 2016 00:24:53 +0100

> Instead, you write your message using something like vi, encrypt it
> from the command line, and then copy and paste the result into your
> mail client.  Then you are certain that your mail was encrypted and
> that you don't accidentally send an unencrypted draft, etc.

If you want to work around your e-mail client, how about an encrypted
attachment?

 - V

---

From: "Neal H. Walfield" <[email-masked]>
Date: Thu, 11 Feb 2016 00:33:23 +0100

Hi,

On Thu, 11 Feb 2016 00:24:53 +0100,
> If you want to work around your e-mail client, how about an encrypted

As I responded to Stephen, I think copy and pasting is more robust.

If you're still not convinced, then replace command line use of gpg
with GPA (the GNU Privacy Assistant).  GPA is a simple GUI that allows
a user to write a message in a notepad-like editor, press encrypt and
then copy and paste the message.  As I understand it, there are some
legitimately scared people who rely on GPA to prevent mistakes.
Complicating the work flow by requiring them to save to disk and then
load a file would be bad for them.

:) Neal

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 11 Feb 2016 00:39:53 +0100

> As I responded to Stephen, I think copy and pasting is more robust.

Didn't see that mail until after I answered, sorry about that.

 - V

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 11 Feb 2016 03:41:53 +0000

>a plain text file that contains the signature, etc.

The "ASCII armoring" was written in order to, among other things, allow PGP
to traverse Fidonet systems running on MSDOS with 2400bps modems.  That's 
what it dates back to.  It should have died a long, long time ago, we can 
send pretty much any other binary-only format over pretty much any medium in 
a manner that's totally invisible to the user, there's no need to still 
retain it.

Peter.

---

From: Werner Koch <[email-masked]>
Date: Thu, 11 Feb 2016 09:57:08 +0100

> to traverse Fidonet systems running on MSDOS with 2400bps modems.  That's 

Right.  And that, along with the slower boxes we had back then, was the reason
for the ASCII Armor's checksum.  I am all in favor of dropping the
requirement for that checksum.

> send pretty much any other binary-only format over pretty much any

That is not true.  How do you want to paste binary data into a contact
web form or a Git commit message?  The OpenPGP Armor makes this really
easy and, fwiw, X.509 uses a similar armoring technique.

Of course you could argue that this should not be part of OpenPGP
proper, but given 25 years of existence it would be surprising to factor
this out to a different RFC.

Regarding PGP/MIME, it might be worth to consider dropping the need for
the ASCII armor in favor of standard MIME encoding.  This would also
help to sort out faulty PGP/MIME implementations.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Feb 2016 09:19:05 +0000

On 10 February 2016 at 09:29, ianG <[email-masked]> wrote:

> In contrast, NaCl encryption authenticates the sender in a repudiable way.

Really? How? I couldn't find any documentation for that.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 12 Feb 2016 13:51:11 +0000

Werner Koch <[email-masked]> writes:

>How do you want to paste binary data into a contact web form or a Git commit
>message?  The OpenPGP Armor makes this really easy and, fwiw, X.509 uses a
>similar armoring technique.

I dunno because that's not my area of expertise, but somehow every other
software mechanism in existence has managed to get by without needing its own
custom "ASCII armoring" (is there anything other than PGP that does this?), so
I'm guessing it's a solved problem.

>Regarding PGP/MIME, it might be worth to consider dropping the need for the
>ASCII armor in favor of standard MIME encoding.  This would also help to sort
>out faulty PGP/MIME implementations.

That would certainly help with usability, since 99.9% of the time it's
completely redundant and better handled through other mechanisms.

Peter.

---

From: Werner Koch <[email-masked]>
Date: Fri, 12 Feb 2016 16:48:05 +0100

> custom "ASCII armoring" (is there anything other than PGP that does this?), so

X.509 and OpenSSL private key format is basically the same - except for
the armor checksum.  You also need that PEM format to paste a CSR into a
CA's web form.

Salam-Shalom,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Fri, 12 Feb 2016 12:06:15 -0500

Peter,

> I'm guessing it's a solved problem.

The only thing custom about PGP's ASCII Armor is the extra CRC.  I agree
that can probably be dropped, except of course there's the
backwards-compatibility issue.  As others have mentioned, there are
definitely reasons to keep *an* ascii armor format, especially for
key/certificate transit (ala an x509 csr/crt submission/retrieval).

> completely redundant and better handled through other mechanisms.

For messages I agree, it's redundant in most current situations.

> Peter.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: ianG <[email-masked]>
Date: Sun, 21 Feb 2016 17:03:32 +0000

On 12/02/2016 17:06 pm, Derek Atkins wrote:
>   As others have mentioned, there are

An additional use is the signature in cleartext signed documents, and 
incorporating the keys into cleartext signed documents so that they 
carry the documents can carry own PKI.

iang

ps; personal bias - above pattern is what I do, and/or was a key 
requirement for my work - but I'm not arguing to keep it for personal 
reasons as I moved away from using OpenPGP for this purpose some time ago.