This article needs additional citations for verification .(December 2019) |
Autocrypt is a cryptographic protocol for email clients aiming to simplify key exchange and enabling encryption. [ citation needed ] Version 1.0 of the Autocrypt specification was released in December 2017. Version 1.1 was released in January 2019. It is implemented on top of OpenPGP replacing its complex key management by fully automated exchange of cryptographic keys between peers [ citation needed ].
Autocrypt-capable email clients transparently negotiate encryption capabilities and preferences and exchange keys between users alongside sending regular emails. [ citation needed ] This is done by including the key material and encryption preferences in the header of each email, which allows encrypting any message to a contact who has previously sent the user email. [ citation needed ] This information is not signed or verified in any way even if the actual message is encrypted and verified. [ citation needed ]
No support is required from email providers other than preserving and not manipulating the Autocrypt specific header fields. [ citation needed ]
When a message is encrypted to a group of receivers, keys are also automatically sent to all receivers in this group. This ensures that a reply to a message can be encrypted without any further complications or work by the user. [ citation needed ]
Autocrypt is guided by the idea of opportunistic security from RFC 7435 but implementing something much less secure than a trust on first use (TOFU) model. Encryption of messages between Autocrypt-capable clients can be enabled without further need of user interaction. [ citation needed ] Traditional OpenPGP applications should display a noticeable warning if keys are not verified either manually or by a web of trust method before use. In contrast, Autocrypt completely resigns on any kind of key verification. Key exchange is during the initial handshake and valid or invalid keys of peers may be replaced anytime later without any user interaction or verification. This makes it very easy to exchange new key(s) if a user loses access to the key but also makes the protocol much more susceptible to man-in-the-middle attacks than clean TOFU. The underlying OpenPGP implementation makes it often possible for the user to perform manual out of band key verification, however by design users are never alerted if Autocrypt changed the keys of peers. [ citation needed ]
Autocrypt tries to maximize the possible opportunities for encryption, but is not aggressive about encrypting messages at all possible opportunities. Instead, encryption is only enabled by default if all communicating parties consent, allowing users to make themselves available for encrypted communication without getting in the way of their established workflows. [1]
Man-in-the-middle attacks are not preventable in this security model, which is controversial. [2]
Any attacker who can send emails with forged sender-address can cause encryption keys to be replaced by keys of his choice and/or deliberately turn off encryption. [3]
Autocrypt uses the established OpenPGP specification as its underlying data format. With Version 1.1 support for Elliptic_Curve_Cryptography (ECC) has been introduced and is the standard for new keys, because it provides the same security with shorter keys. [4] For this Curve25519 is used. [5] Messages are encrypted using AES and RSA keys, with a recommended RSA key length of 3072 bits. These mechanisms are chosen for maximum compatibility with existing OpenPGP implementations. There are plans for moving to smaller Elliptic-curve keys when support is more widely available. [6]
The Autocrypt
header field features a tag=value
format common to several mechanisms (for example dkim), where the keydata
tag contains the public key. It is similar to an armored key export, except that it misses the -----BEGIN PGP PUBLIC KEY BLOCK-----
and -----END PGP PUBLIC KEY BLOCK-----
lines. [7]
For example:
Autocrypt:addr=alice@autocrypt.example;prefer-encrypt=mutual;keydata= mDMEXEcE6RYJKwYBBAHaRw8BAQdArjWwk3FAqyiFbFBKT4TzXcVBqPTB3gmzlC/Ub7O1u12 0F2FsaWNlQGF1dG9jcnlwdC5leGFtcGxliJYEExYIAD4WIQTrhbtfozp14V6UTmPyMVUMT0 fjjgUCXEcE6QIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDyMVUMT0fjj kqLAP9frlijwBJvA+HFnqCZcYIVxlyXzS5Gi5gMTpp37K73jgD/VbKYhkwk9iu689OYH4K 7q7LbmdeaJ+RX88Y/ad9hZwy4OARcRwTpEgorBgEEAZdVAQUBAQdAQv8GIa2rSTzgqbXCp DDYMiKRVitCsy203x3sE9+eviIDAQgHiHgEGBYIACAWIQTrhbtfozp14V6UTmPyMVUMT0fj jgUCXEcE6QIbDAAKCRDyMVUMT0fjjlnQAQDFHUs6TIcxrNTtEZFjUFm1M0PJ1Dng/cDW4xN 80fsn0QEA22Kr7VkCjeAEC08VSTeV+QFsmz55/lntWkwYWhmvOgE=
{{cite web}}
: CS1 maint: multiple names: authors list (link)