Future Enhancements to Autocrypt

Please see Autocrypt Level 1: Enabling encryption, avoiding annoyances for information about Level 1 requirements. Here, we document future improvements, which we hope will be incorporated in Level 1, or possibly some later Level. This is an unordered list. If you have ideas about how to address one of these points, feel free to jump in! (but let’s try to stay focused on getting Level 1 stable before we invest too much energy in these next steps)



We need documentation about sensible key expiry policies. Autocrypt-capable MUAs that choose to have an expiry policy on their secret key material should use message composition as an opportunity to refresh their secret key material or update the expiration dates in their public certificate.

Client sync

Please see Multi-Device Pairing Considerations


We need to specify how to sync internal Autocrypt state between MUAs. We want to be able to sync the state without sending sync data for every message processed, while we also want all synced peers to have the same internal state as much as possible. We currently believe that syncing updates to pah and changed should be sufficient, and that peers do not need to sync last_seen. This has not been proved in practice.

New Types


how to deal with multiple types (at least when a new type is specified). When we support types other than 0, it’s possible that users will have multiple keys available, each with a different type. That seems likely to introduce some awkward choices during message composition time, particularly for multi-recipient messages.

X.509 and S/MIME


Someone is bound to ask for this as a “key type”

Deletable (“forward secure”) encrypted mail


Given the Autocrypt infrastructure for key exchange, there’s no reason we couldn’t define a mechanism for pairwise, ratcheted, session-key establishment for e-mail.

RSA3072 to Curve 25519


Document change in preference for keys from RSA 3072 to Curve 25519.


see Autocrypt Secret Key Backup


We need guidance on how backups might be done safely.

Guidance on masking Key IDs

If any recipients are in Bcc: (rather than To: or Cc:), and the keys used are all OpenPGP, then the MUA SHOULD mask the recipient key ID in the generated PKESK packets that correspond to the Bcc’ed recipents. It does not need to mask recipient key IDs of normal recipients.

Masking of Key IDs is done by setting the key ID to all-zeros. See the end of section 5.1 RFC 4880 for more details. Users of GnuPG can use the --hidden-recipient argument to indicate a recipient who will be masked.

This is so that the message encryption does not leak much additional metadata beyond what is already found in the headers of the message. It still leaks the number of additional recipients, but the additional work and usability issues involved with fixing that metadata leak suggest that it’s better to leave that to a future level.

Encrypted headers


Document interaction with encrypted headers: if something like Memory Hole ever makes it possible to hide normal To: and Cc: headers, then we need to rethink our approach to handling PKESK leakage further.



How does Autocrypt interact with webmail? Can we describe hooks for webmail and browser extensions that make sense?

Gossip (or “introduction e-mails”)


Can we specify a sensible practice for passing around keys for other people that we know about?

Or maybe it’d be simpler to define a standard workflow for “introduction e-mails”, where the sender tells multiple recipients about the keys she has for all of them.

Out-of-band key verification


Can we specify a simple, user-friendly way that Autocrypt users can confirm each others’ “Autocrypt info” out of band?

If we do specify such a thing, what additional UI/UX would be required?

Heuristics for dealing with “nopreference”


in Level 1, the Autocrypt recommendations for composing mail to a remote peer with prefer-encrypted set to nopreference look very much the same as the recommendations for when prefer-encrypted is set to no. But different heuristics could be applied to the nopreference case for MUAs that want to help users be slightly more aggressive about sending encrypted mail.

Documenting reasonable heuristics for MUAs to use in this case would be very helpful.