[openpgp] New encryption formats for messaging

[David Leon Gil <[e-mail]>]

Some desiderata, generally:

A0. Be as secure as possible by default. Do not offer options to
fallback to doing unsafe things. "Experienced" users often think they
want them; there are usually better solutions for their use-cases.

A1. Only specify a single asymmetric encryption scheme and a single
asymmetric signature scheme. This is critical: This is the second most
dangerous and buggy code in any crypto scheme.

A2. Clearly separate handling of various message and key metadata from
the underlying encryption scheme. This is critical: Parsing code is
the most dangerous and buggy code in any crypto scheme.

A3. Do not specify things which are infeasible to thoroughly test.
This implies avoiding combinatorial complexity, which the OpenPGPv4
spec doesn't.

A4. All messages, including signed but unencrypted messages, should be
indistinguishable from random to an adversary who does not know the
public key of the signer. (This is, essentially, a Tor-style security
requirement.)

Some desiderata for symmetric primitive choices:

B1. Only modern hash functions that provide a significant security
margin against cryptanalysis. Let's not repeat the MD-5/SHA-1
disaster. (We only need two hash functions at most.)

B2. Only block and stream ciphers that offer a significant margin of
safety against cryptanalysis. (Or that, when composed, offer a
significant margin of safety against cryptanalysis.)

B3.. A single AEAD mode that is maximally misuse-resistant, in the
sense of https://eprint.iacr.org/2014/793. (But probably not AEZ, or
any other CAESAR competitor for that matter. I would prefer a scheme
that uses generic composition of well-studied primitives.)

Thus, what any proposal should specify, at the crypto level:

C1. A single curve providing security above the 192-bit-equivalent
level. (This is because the *tightest* security reductions for any
concrete instantiation of EC primitives result in a security level of
~ 120-bits for a 384-bit curve.)

C2. A single message format intended for use with signed and encrypted
messages of length >> 128 bytes and << 2^24 bytes. (That is, something
appropriate for email. I would consider encryption of large files and
very short messages out of scope at this time.) I am agnostic as to
whether encrypted-then-signed or signed-then-encrypted is preferable.
I am curious if anyone else has strong views on this?

C3. A single message format intended for detached signatures. This
should target, specifically, the common use-case of OpenPGP signatures
for code-signing.

C4. Specify a mechanism for encapsulating a signature over the body of
an HTML email in a way that is compatible with HTML email as commonly
used. This signature should be indifferentiable from random for anyone
who does not know the public key of the sender.

(This last should be easy. A concrete proposal: If a
"data-openpgp-sig" attribute is present on a tag, it contains a
base64urlsafe-encoded signature over the contents of that tag, with no
special normalization rules applied. This can be made more precise by
reference to the HTML5 spec.)

And what a proposal should specify, for various key and message metadata:

D1. A standard format for encapsulating arbitrary key and message metadata.

D2. Mappings from OpenPGPv3 metadata to that format, as appropriate.

--

Final comment:

I am, quite frankly, agnostic as to whether an IETF WG or another
forum is the most appropriate place to specify something.

The IETF lately has not seemed to be so much about canonizing "de
facto" standards (which it was good at) as design-by-committee (which
it isn't). And recent revelations have shown that design-by-committee
is -- besides being irritating for implementors -- a boon to
intelligence agencies.

So: I would encourage anyone interested in seeing something
standardized to make a complete proposal a la Hugo Krawycz's OP-TLS
proposal for TLS1.3. But implement the proposal first. Working code
&c.

Taking a scattershot approach will lead to a shoddy, messy, unsafe
result. Yahoo will not support a specification that, by sloppiness or
untestability, makes our users unsafe.

David Leon Gil
Senior Paranoid
Yahoo!