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, [email protected] 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
signature.asc
Description: PGP signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
