S/MIME’s four functions, and DKIM’s domain signature

S/MIME: four functions, and only one of them is a security feature you can see

S/MIME is the Internet standard for e-mail security, and it carries the same functionality as PGP: confidentiality, origin authentication, and integrity, layered onto MIME. It offers four functions, and the exam-relevant differences between them are about what gets encoded, not what gets signed.

Worked example. Priya sends Omar one short message — Board pack attached. Do not forward. — four different ways.

(1) Enveloped data. S/MIME generates a fresh pseudorandom symmetric key for this message only, encrypts the content with it (AES by default), and then encrypts that key under each recipient's public key, shipping the encrypted keys alongside the encrypted content. This is the hybrid construction: one cheap symmetric pass over the body, one expensive public-key operation over a short key, repeated per recipient. Omar recovers the content key with his private key and then decrypts the body.

(2) Signed data. Priya's software hashes the content with SHA-256 and encrypts the 256-bit digest with her own private key — the public-key operation therefore covers only 256 bits and is fast. Then the content and the signature together are base64-encoded. The consequence follows immediately and is what gets examined: to a recipient without S/MIME, the whole thing is a wall of base64. Only an S/MIME-capable recipient can read it at all.

(3) Clear-signed data. Identical signature, different packaging: only the signature is base64-encoded, and the content is left as it was. A recipient without S/MIME can read the message perfectly well but cannot verify it. Signature present, verification impossible, content legible.

(4) Signed and enveloped data. The two nest, in either order: encrypted data may be signed, and signed or clear-signed data may be encrypted.

Why base64 at all? Because a signature is a binary string, and some mail software inspects message content looking for control characters such as line feeds, so raw binary risks being altered in transit. Base64 maps every three octets of binary onto four printable ASCII characters — a 33% expansion, paid to survive the mail system.

DKIM: the same problem, one layer down, signed by somebody else

DKIM lets a signing domain claim responsibility for a message by signing it with the domain's private key. The verifier does not need a certificate: it queries the signing domain over DNS and retrieves the public key from there. If a message claims to come from kestrel.example but fails the check, it can be rejected.

DKIM exists because of five specific things S/MIME cannot do. S/MIME requires both parties to have deployed it, and most correspondents have not. S/MIME covers the message content only, leaving the origin headers open to tampering — which is exactly what a forger rewrites. DKIM lives outside the client, in the submission or delivery agent, so the user has nothing to install and nothing to do. DKIM covers every message leaving a cooperating domain, not just those a user opted into. And it lets a good sender prove authorship and stops a forger masquerading as that sender.

The five-axis contrast — write it as one table, not two lists

These two are the confusable pair, and the paper's way of asking is to give you one axis and see whether you have the other four:

The default signing algorithm for DKIM is RSA with SHA-256, and S/MIME commonly signs with RSA or DSA over an SHA-256 digest — so the cryptography is nearly identical in both. Everything that separates them is a question of who holds the key and where the code runs, which is why they are complements rather than competitors: DKIM says a message really left the domain it claims, and S/MIME says a particular human wrote it.