S/MIME: A Central Approach

S/MIME [4], the second known mail encryption method, basically encrypts and signs in a way comparable to PGP but takes a more centralized approach to key generation and management. S/MIME certificates are issued, monitored, and declared invalid if necessary by a central certification authority. S/MIME is therefore suitable for structured use in a very controlled environment, for example, in public authorities or large companies. It is not surprising that classic business mail clients such as Outlook have always supported S/MIME natively.

On the other hand, S/MIME is less practical for private use, because there is initially no sensible centrally organized certification authority. Many years ago, there was an attempt by savings banks to issue S/MIME certificates to the masses via the S-Trust project, but this initiative did not catch on. The most practicable approach to date appears to be the Volksverschl¸sselung (People Encryption) project [5], which is run by the Fraunhofer Institute [6], which is worthy of recommendation but has not achieved widespread acceptance.

Unencrypted Metadata

If an email is encrypted using PGP or S/MIME, the encryption affects the entire body of the email, including the message text and any file attachments. The metadata of the mail header (i.e., information such as sender, recipient, message ID, and date) remains readable. The subject of an email is also classically part of the non-encrypted header data of an email. If desired, modern PGP implementations can also hide the subject in the encrypted body of the message so that it only becomes readable after decryption.

Encrypting in the Mail Client

If a mail program like Thunderbird encounters an encrypted message, it first identifies the key IDs used to encrypt the message and then checks whether there is a secret key for decrypting it in the internal keyring. If so, the program prompts the user to unlock their own key by entering a password. The mail can then be read normally and without any problems and, if required, displayed in the inbox together with the subject.

It makes sense for the mail program to keep the decrypted key in memory for a longer period of time, so that it can be used for hours without entering a password. The user can thus conveniently and transparently read and edit countless encrypted messages without even noticing that the messages are currently being decrypted in the background. It is only after a longer period of inactivity or after restarting the mail program that the user has to enter the key password again. This approach ensures maximum usability but theoretically also harbors the risk that an attacker could read the unsecured key from RAM.

To send an email, on the other hand, the generally known and password-free public key of the recipient is used if it exists. If a message is sent to several recipients, the emails can be encrypted simultaneously with the keys of all recipients and thus opened by all of them without any problems. The only minor disadvantage is that experts could identify hidden BCC recipients on the basis of the key they now use in the email. By the way, if the sender's own address is included in the distribution list, the copy sent back to the sender is also encrypted by default.