0 / 8
ENCRYPTED: Sign it and encrypt the body too
PEM (Privacy-Enhanced Mail) handles signing and encryption only at the two ends, the sender and the recipient. ENCRYPTED is the type that adds a signature and also encrypts the body.
The mail servers in between do not need to know PEM and pass the message along unchanged.
Example: Alice sends Bob a message saying “Meeting at 3 tomorrow”.
What a mail server sees as the body is ciphertext.
1 / 8
Alice: Make the MIC of the body
Alice puts the body into the standard mail format (line endings and so on) and feeds it to a hash function to get the MIC (Message Integrity Check) a41f. The MIC is a short value that changes if even one character of the body changes.
2 / 8
Alice: Sign the MIC
Alice encrypts the MIC with her own private key to make the signature 7be2. Only Alice has her private key, so only Alice can make this signature. Alice signs the short MIC, not the whole body.
3 / 8
Alice: Encrypt the body with the DEK
Alice creates a new key just for this message, the DEK (Data Encrypting Key) k58. Encrypting the body with the DEK gives the ciphertext x9Fq…. A new DEK is made for every message. The body is encrypted with this one DEK only.
4 / 8
Alice: Encrypt the DEK with Bob's public key
Only Bob should know the DEK. So Alice encrypts the DEK with Bob's public key to get c3d9. A value encrypted with a public key can be opened only with the matching private key, Bob's.
5 / 8
Alice → Bob: Send the message
The signature is encrypted once more with the same DEK. The signature and the encrypted DEK go in the header part of the message, and the ciphertext goes in the body part after a blank line. These values are written as characters that survive mail transport (encoding), and everything is placed between the BEGIN and END boundary lines. The mail server treats it as ordinary mail text and passes it on. What the mail server sees as the body is ciphertext, which it cannot read.
6 / 8
Bob: Take out the DEK
Bob decodes the encrypted DEK in the header part back from characters, then opens it with his own private key to get k58. Bob's private key belongs to Bob alone, so mail servers and other people cannot get the DEK.
7 / 8
Bob: Decrypt the body
Bob decodes the characters in the body part to get the ciphertext, then decrypts it with the DEK k58 to read the body “Meeting at 3 tomorrow”. Decoding the signature in the header part and decrypting it with the same DEK gives 7be2.
8 / 8
Bob: Check the signature
Bob opens the signature 7be2 with Alice's public key and gets the MIC a41f. The MIC recomputed from the received body is also a41f, so the two values match. The body therefore was not changed (integrity). Only Alice can make the signature, so it is confirmed that Alice is the sender (sender authentication). With the public-key method, it is also hard for Alice to deny having sent it (non-repudiation of origin).
1 / 6
Alice: Make the MIC of the body
Alice puts the body into the standard mail format (line endings and so on) and feeds it to a hash function to get the MIC (Message Integrity Check) a41f. The MIC is a short value that changes if even one character of the body changes.
2 / 6
Alice: Sign the MIC
Alice encrypts the MIC with her own private key to make the signature 7be2. Only Alice has her private key, so only Alice can make this signature. Alice signs the short MIC, not the whole body.
3 / 6
Alice: Turn the body into characters
This type does not encrypt the body. Alice only turns the body into characters that survive mail transport (encoding) and gets 6Ky1b…. The conversion keeps the text from being damaged while the message is delivered, so no DEK is needed.
4 / 6
Alice → Bob: Send the message
The signature is turned into characters and goes in the header part. The encoded body goes in the body part after a blank line, and both are placed between the BEGIN and END boundary lines. What the mail server sees as the body is encoded characters that are hard to read as they are. This is not encryption, so anyone who knows the encoding can turn it back into the original text.
5 / 6
Bob: Turn the body back
Bob turns the encoded characters back to read the body “Meeting at 3 tomorrow”. The conversion needs no key, so Bob's private key is not used.
6 / 6
Bob: Check the signature
Bob opens the signature 7be2 with Alice's public key and gets the MIC a41f. The MIC recomputed from the received body is also a41f, so the two values match. The body therefore was not changed (integrity). Only Alice can make the signature, so it is confirmed that Alice is the sender (sender authentication). With the public-key method, it is also hard for Alice to deny having sent it (non-repudiation of origin).
1 / 6
Alice: Make the MIC of the body
Alice puts the body into the standard mail format (line endings and so on) and feeds it to a hash function to get the MIC (Message Integrity Check) a41f. The MIC is a short value that changes if even one character of the body changes.
2 / 6
Alice: Sign the MIC
Alice encrypts the MIC with her own private key to make the signature 7be2. Only Alice has her private key, so only Alice can make this signature. Alice signs the short MIC, not the whole body.
3 / 6
Alice: Leave the body readable
This type neither encrypts the body nor turns it into characters (encoding). Kept in the standard format set earlier (line endings and so on), the body stays as the readable text “Meeting at 3 tomorrow”.
4 / 6
Alice → Bob: Send the message
The signature is turned into characters and written in the header part, and the readable body goes in the body part after a blank line, all between the BEGIN and END boundary lines. Even a mail program without PEM support can show the body. But only a program that supports PEM can check the signature. If a mail server changes the body even slightly, the check may fail.
5 / 6
Bob: Read the body
Bob has nothing to decrypt or turn back and simply reads the body “Meeting at 3 tomorrow”.
6 / 6
Bob: Check the signature
Bob opens the signature 7be2 with Alice's public key and gets the MIC a41f. The MIC recomputed from the received body is also a41f, so the two values match. The body therefore was not changed (integrity). Only Alice can make the signature, so it is confirmed that Alice is the sender (sender authentication). With the public-key method, it is also hard for Alice to deny having sent it (non-repudiation of origin).