[messaging] Fwd: alternative to OpenPGP?

[Mansour Moufid]

Oops, I didn't "reply to all":


---------- Forwarded message ----------
From: Mansour Moufid <mansourmoufid at gmail.com>
Date: Thu, Aug 13, 2015 at 5:35 PM
Subject: Re: [messaging] alternative to OpenPGP?
To: Daniel Kahn Gillmor <dkg at fifthhorseman.net>


On Thu, Aug 13, 2015 at 2:13 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:

>> [1] https://medium.com/@nweaver/extra-unofficial-xkeyscore-guide-b8513600ad24
>
> The point Nick Weaver is making here about metadata is actually about
> the place where most OpenPGP encrypted content is found: e-mail.  the
> e-mail message itself (and its SMTP transport) exposes metadata, even if
> the OpenPGP message bodies are encrypted.  If you're talking about
> replacing OpenPGP in an e-mail context you won't solve the problem
> Weaver is pointing out.

Key ID reveals no more information than was in an email, agreed.

But consider a PGP message sent through an anonymous remailer...

> The OpenPGP message format itself does expose a little bit of metadata
> in encrypted packets: in particular, the Key ID field of the Public Key
> Encrypted Session Key (PKESK) packet suggests whose key the message is
> encrypted to:
>
>  https://tools.ietf.org/html/rfc4880#section-5.1
>
> The standard itself suggests using all-zeroes there to minimize that
> metadata leakage:
>
>    An implementation MAY accept or use a Key ID of zero as a "wild card"
>    or "speculative" Key ID.  In this case, the receiving implementation
>    would try all available private keys, checking for a valid decrypted
>    session key.  This format helps reduce traffic analysis of messages.

Key ID is interesting for another reason: it's an indicator of an
outdated methodology.  Modern reasoning is that if something is
optional it shouldn't exist.

The trend in writing standards or designing protocols is to try to
anticipate implementation bugs very early on.  What used to be strictly
engineering concerns, like minimizing attack surfaces, should be part
of a standard.  We see it in low-level cryptography, authenticated
ciphers replace encrypt-then-MAC, EdDSA replaces ECDSA, etc.

>> [2] http://www.ssi.gouv.fr/uploads/2015/05/format-Oracles-on-OpenPGP.pdf
>
> These are real concerns, and they're tangled up at least as much with
> API issues as with underlying message format issues.  This means that
> you need to think about how you use your underlying crypto library at
> least as much as how the data itself is packaged.
>
> As far as the data format goes, the OpenPGP symmetrically-encrypted
> packet format is a hoary legacy from older times, and definitely needs
> improvement.  We plan on replacing it in the upcoming revision of the
> OpenPGP standard, probably with some modern AEAD mechanism.  If you'd
> like to make suggestions about that, openpgp at ietf.org is probably the
> right place to have that conversation.

This is what makes me look away from OpenPGP.  I couldn't contribute
anything without understanding it fully, which I don't because it's
too complicated.

I want something modern, simple enough that even I can implement, and
with enough consensus that anything I do implement is compatible with
other implementations.  I hope this conversation signals to people who
have the authority to create consensus that there is a real demand for
a new format.

By the way, I'm not a proponent of the "revolution or nothing" school
of software security.  OpenPGP and its implementations can and I'm
sure will continue to improve.  But there is a need for innovation.

>> So I'm looking for an alternative message format which: has minimal
>> metadata; requires authenticated encryption; and is trivial to parse
>> with Hammer.
>
> Are you talking about http://hammer-language.com/ ?  this is an odd
> request to tack on to the end of this message :) I know nothing about
> Hammer, sorry.

Sorry, I should have linked: https://github.com/abiggerhammer/hammer


Yours,
Mansour