Opportunistic Crypto Technical Notes

The Opportunistic crypto system would insert a header into outgoing mail.

This header, in MIME field=value syntax, would include:

1. At the minimum, the user's public key, or a hash "fingerprint" of the key and a URL of a place where the key could be found on the net. This would be coded for the default (and it turns out, only) signing and encrypting method used in this system. This key, however might be replaced by a simple flag saying, "I know you have my key already, keep using it."
2. Optionally, a tag indicating what the encryption and signing algorithms are for use of this key, and any version numbers, should they ever change. As you'll see below, there are reasons why they should not be expected to change.
3. Optionally, or in another header, an encoding of one or more "ceritificates" for the above key if one exists, or the URL of such certificates.
4. Optional flags indicating that the user has the target's key already, no need to re-send it in replies.
5. A flag to indicate this key belongs to a forwarder (mailing list) that is forwarding the mail, and not the original sender. A certificate will also do this.

Why won't it change?

While good formats allow you to select from a variety of options and extensions, there are times when this is not valuable. If there are, for example, two algorithms one can use to encrypt a message, all that means is that all encrypters are forced to be able to do both. If you allow your target to tell you what algorithm to use to meet their tastes, you just add complexity to every sender's encryptor. And everybody has both, so there is no merit in this.

The only time you would want to be able to choose your algorithm is if there is some reason you can't use one of them. For example, one might be broken (in which case everybody should switch) or some might be illegal in some places. However, one hopes one can design the first choice of algorithm to make this unlikely.

It's also possible a new algorithm might come along that is much better, ie. has shorter keys or requires less CPU. Or the laws restricting such algorithms might be relaxed. (For example, ECC probably is better than RSA, but it is patent encumbered.) However, since everybody has to be able to send using all the defined algorithms, it really makes the most sense for everybody to use the best one right from the start.

So I feel the right task is to pick one algorithm, but allow the format to later add an optional tag that can change or revise the algorithm.

Encrypting and signing the headers

The message will be encrypted into the body of the message. This body will contain not just the text of the message, but also replacements for many of the headers. The encrypted message will contain no subject line and minimal headers necessary for transport (almost none, mostly the Received headers added in transport, and the required Date and From line, though the From line could be a dummy entry. It would then have the MIME Content-type: multipart/encrypted header.

In the encrypted and signed body would be the real headers of the message, and the real body of the message.

Of course the message would have the sender and recipient in the "envelope" of the SMTP process, not strictly in the header. These are necessary to deliver the mail and for bounces and errors to be returned. Users not interested in errors could even fake the envelope-From but this may cause some mailers to not deliver their mail.

All the true headers (including MIME headers of a MIME message) would be in this special body. When the user's "mail user agent" sees the message, it will be restored to be normal looking, but some headers would be added to it to report on the fact that it was encrypted and that the source was verified.

In the key block would reside a fingerprint for the key that the message was encrypted with, any flags about the version or algorithm for encryption or signing, and any signature with associated information.

Also in the key block would be a header revealing, if the user doesn't already have it, the key of the sender for any replies to the sender, much like the header sent out on first-time E-mails to parties.

The body will also contain a note, in plain text, that the message is encrypted, and a pointer to a URL explaining the system and how to read it. This would normally only be seen by people who try to read mail from another machine, or who lose their MEA program or plug-in and see their raw mailbox again. The URL would of course contain help on how to fix that problem and re-install the MEA.

Perhaps No Certificates

Certificates are such a great idea that they are assumed as a given in the design of email encryption and authentication systems. However, I have started wondering if they should be used, even for those who want to go to the effort to get one.

A certificate is??

Bounces

When mail bounces, many MTAs don't return the full message. With the use of encryption, this may mean limited data comes back in a bounce. The MEA (Mail Encrypting Agent) may wish to keep outgoing messages for a limited time, in able to handle bounces and produce something meaningful.

After all, even if you get a bounce you still can't read it, only the recipient is able to decode it.

What about PGP/GPG

The wide availability of GPG code might make it a choice for the means of encoding the message headers and bodies. The actual format will never been seen by any MUA, only by MTAs. However, at least in my opinion, the PGP format is a fairly ugly one, not in line with more modern ideas of format and protocol design. PGP was a groundbreaking program whose release in the face of laws required exceptional bravery, but I'm afraid I can't endorse it as the best designed crypto format available to us.

Mailing Lists

Mail to mailing lists would need to be specially identified. Ordinary mailing lists will just pass along key headers, but replies to the list must not be encrypted with that key, only replies to the actual individual. It will be possible for mailing lists to become compliant with this protocol, including a key for the list so that mail to the list is encrypted, then at the list handler, decrypted and then re-encrypted for every recipient who uses encryption.

However, it should be noted that unless the mailing list is very closely managed, mail to a list should not normally be expected to be secure.

In general, mail to multiple parties will not be very secure unless keys are known for all the parties. It's still worth doing since those who do have keys will still want their privacy protected, and only the most determined privacy invaders would be snooping all parties in a conversation.