Up to now, the use of end-to-end encryption has been very rare. This can be explained partly by the fact that the manufacturers of the most commonly used e-mail programs do not offer this encryption technology. Users must make the effort to extend their e-mail programs with the relevant plug-ins themselves. Even though the installation and configuration processes have become considerably more user-friendly in recent years thanks to extensive automation, applying the technology continues to be made more difficult by the complex key distribution process involved.

For this reason, the below lists the most important considerations you should bear in mind when using asymmetric encryption:

Follow the same rules for the data exchange

In order to allow senders and recipients to communicate with each in encrypted form, the e-mail programs must both support the same required protocols.
Currently, two standard protocols have been established for encrypted e-mail communication, S/MIME and OpenPGP.

In the context of public authorities and companies, it is mostly the S/MIME protocol that is used to exchange e-mails, whereas OpenPGP is used in the private sphere. Although both use the same algorithms and mechanisms for the cryptography, there are differences in how they manage the keys that make them incompatible. For this reason, the communication partners must agree in advance which standard is more appropriate in the usage scenario if they decide to use encryption. Some e-mail programmes require an appropriate plugin in order to execute the encryption, which needs to be installed and configured to suit the choice of protocol.

S/MIME

The S/MIME (Secure/Multipurpose Internet Mail Extensions) encryption protocol is already integrated into many home e-mail programs. It might be preset or it might need to be activated by users themselves. If the function is activated, two selection fields appear, generally in the top menu of the e-mail program. One activates the digital signature and one encrypts the e-mail. These can be selected for each e-mail, unless it has been automated for all e-mails by being preset. The key pairs required are not typically created by the users themselves, but rather by organisations or companies, normally for a charge. For this reason, S/MIME is primarily used for companies or public authorities and less so for private use. As such, S/MIME will not be considered any further here.

OpenGPG

PGP (Pretty Good Privacy) is a piece of commercial encryption software. GPGP or GNuPG (GNU Privacy Guard) is its open-source software equivalent. Both implement the OpenPGP open standard.

With OpenGPG, the user can issue and manage all of the keys themselves. Either the user is directly supported by the e-mail program when applying the key, or a plugin has to be installed to carry out this task.

The following programs and plugins are available for users to choose from:

Collection of tools for Apple OS X including plugin for Apple Mail: gpgtools.org/

Collection of tools for Windows including plugin for Outlook: www.gpg4win.org/index-de.html

Enigmail for Thunderbird within Linux, Mac OS X and Windows: www.thunderbird-mail.de/wiki/Enigmail_OpenPGP

You can find information on the encryption program Gpg4win here

Verifying and exchanging keys

The advantage of the asymmetric process is that the public key can also be exchanged via non-secured means, because it is not secret. However before using it, the recipient should ensure that the key really belongs to the address stated. The more insecure the source that the key is received from, the more essential it is to verify the key.

The private key, on the other hand, must not be lost or end up in third-party hands.

Exchanging keys via key servers

A key server does not check that the key is allocated to the e-mail address when the owner uploads the public key. As such, other people can also upload this public key to the key server even though they are not the owner, which is not a problem because the key is also meant to be published. However, it is possible for someone to create their own public key associated with a third-party's e-mail address and upload it to the server.

If communication partners then search for the public key of an addressee using their e-mail address on the key server, they will find more than one matching key, meaning the users cannot find the correct one without further assistance. If the wrong key is used, the authorised recipient of the e-mail cannot decrypt it, but the person who uploaded the false key can.

Exchanging keys by e-mail

Another option may be to send the public key to the communication partner by e-mail openly. With this process also, the authenticity of the public key is not guaranteed. For example, an attacker could use a "Man-in-the-Middle-Attack" to intercept this e-mail and replace its key with their own public key. The communication partner would then unknowingly encrypt their message using the public key of the attacker, who could then read the message using their private key. It therefore cannot necessarily be guaranteed that the key is correctly allocated to the associated e-mail address. The manner in which the key is received also determines how reliably its authenticity can be trusted.

Experienced users can also compare the unambiguous checksum of a key (its hash value) when exchanging the keys via another communication channel in order to determine its authenticity. However, this requires additional effort and a willingness to play a more active role at the technical level.

Automated verified key exchange using EasyGPG

With the new e-mail encryption process EasyGPG, the BSI has simplified the process of exchanging public keys and created a way of sending them automatically and directly via the e-mail provider. You can find more information about this under "E-mail Encryption: Key Exchange Made Simple".