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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp