[messaging] alternative to OpenPGP?

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Aug 13 11:13:32 PDT 2015


On Thu 2015-08-13 12:17:08 -0400, Mansour Moufid wrote:

> metadata; [1]
> [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.

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.

> format oracles; [2]
> [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.

> difficulty of implementation. [3]
> [3] See GnuPG.

GnuPG isn't the only implementation, and may not be the best tool for
your choice.  Take a look at OpenPGP.js and hOpenPGP -- there are other
parsing libraries available (though i agree the range of choice isn't
large enough).

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

If you're just looking for a simple symmetrically-encrypted message
format with no interoperability concerns and no legacy installed base,
and you don't plan to use it within an e-mail context, you might want to
look at the crypto_box mechanisms for nacl or libsodium:

 https://libsodium.org/
 http://nacl.cr.yp.to/

hth,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150813/a7155710/attachment.sig>


More information about the Messaging mailing list