Oops, I didn't "reply to all":
---------- Forwarded message ---------- From: Mansour Moufid <[email protected]> Date: Thu, Aug 13, 2015 at 5:35 PM Subject: Re: [messaging] alternative to OpenPGP? To: Daniel Kahn Gillmor <[email protected]> On Thu, Aug 13, 2015 at 2:13 PM, Daniel Kahn Gillmor <[email protected]> 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, [email protected] 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
