What is PDF email encryption?
The gateway supports three ways to protect email: S/MIME, OpenPGP, and PDF encryption. S/MIME and OpenPGP provide end‑to‑end encryption and are the most secure options when both sender and recipient have the required keys set up. In practice, they require each party to use an S/MIME‑ or PGP‑capable mail client and to install and maintain a personal certificate (S/MIME) or key pair (PGP). This setup is ideal for frequent, ongoing secure communication, but it can be too much overhead for occasional recipients who only need to exchange a few protected messages. As a more lightweight alternative, the gateway can use PDF encryption. With this method, the complete email—including all attachments—is converted to a single PDF file and protected with a password. The encrypted PDF is then attached to a new, simple notification email. The notification email contains only a generic note indicating that an encrypted PDF is attached; it does not include message content or sensitive details. PDF encryption uses AES‑128. The AES‑128 encryption key is derived from the password. Because most recipients already have a PDF reader, they can open the protected content without installing additional software—only the password is needed.
When choosing between methods:
Use S/MIME or PGP when you and your recipients can manage certificates or keys and you expect regular secure exchanges. This offers the strongest end‑to‑end model and seamless replies within the mail client.
Use PDF encryption when recipients do not have S/MIME or PGP set up, or when secure email is infrequent. This minimizes setup for the recipient while still protecting message content and attachments.
Recipient experience with PDF encryption:
The recipient receives a notification email with an encrypted PDF attached.
The recipient opens the PDF in their usual PDF reader.
The reader prompts for the password. After entering the correct password, the recipient can read the original message and access any embedded attachments.
Best practices for PDF passwords:
Share the password through a separate channel (for example, SMS or a phone call) to reduce risk if the email is intercepted.
Use a strong password that is hard to guess but practical for the recipient to enter.
Avoid reusing passwords across different recipients or messages unless your policy requires it.
With PDF encryption, are attachments encrypted as well?
Attachments are added to the PDF before encryption, so they are encrypted along with the document. To view or save the attachments, use a PDF reader that supports file attachments, such as Adobe Acrobat.
Is PDF encryption safe? Some companies claim they can crack PDFs?
PDF encryption is secure when protected with a strong password and encrypted using AES‑128. Attackers typically attempt to guess passwords using techniques like dictionary lists of common words and names. To prevent this, the gateway can automatically generate a unique, random password for each PDF. By default, it uses 16 bytes (128 bits) of cryptographically random data, providing a very high level of resistance against password‑guessing attacks.
With PDF encryption, how can the recipient securely reply ?
The gateway can be set to include a Reply link in outgoing messages. When a recipient clicks this link, their web browser opens a secure page on the CipherMail gateway where they can compose and send a reply.
There are different password modes for PDF encryption. Which mode is the most secure?
You can protect a PDF with a password using several modes. The PDF can be encrypted with a pre-defined static password. It can be encrypted with a randomly generated password that is sent to the recipient by SMS text message. It can be encrypted with a randomly generated password that is sent back to the sender by email. It can also be encrypted using a one-time password (OTP) algorithm.
For all modes, it is essential to choose a password that is sufficiently long and complex to resist brute-force attacks.
There is no single answer to which mode is most secure, because it depends on your use case and threat model. For example, a static password can be very secure if it is strong and properly managed. However, when using a static password, every PDF sent to the same recipient is protected with the same password. If an attacker discovers that password, all such PDFs can be opened. The following sections provide a brief overview of the advantages and disadvantages of each mode.
Static password
Pros:
Easy to setup. The recipient only requires one password.
Cons:
The password has to be securely exchanged with the recipient.
All PDFs are encrypted with the same password.
Long passwords required to protect against brute force attacks.
Random password via SMS
Pros:
The password is sent via a different channel (SMS) than email. An attacker needs access to the email and SMS to read the email.
Every PDF can be encrypted with a different randomly generated password.
Cons:
The recipients needs a telephone number to which the SMS can be delivered.
The sender has to provide the SMS telephone number.
Reading the password from the SMS can be cumbersome, especially with long passwords.
If the password for the PDF is lost, the recipient can no longer open the PDF.
SMS messages are not free.
Random password, sent back to sender
Pros:
The password can be sent via a different communication channel.
Every PDF can be encrypted with a different randomly generated password.
Cons:
The sender somehow needs to exchange the password with the recipient using a secure channel.
Typing the password into the PDF password dialog can be cumbersome, especially with long passwords.
If the password for the PDF is lost, the recipient can no longer open the PDF.
One Time Password (OTP) using the online portal
Pros:
Every PDF is encrypted with a different randomly generated password.
The generated password can be copied and paste into the password dialog. The password can therefore be very long.
Because the recipient has to log into the portal to generate the password, online security against brute force attacks can be used.
Since the password is generated using a server stored client secret, the PDF password can always be generated.
The recipient has to log into the portal to generate the password. The account can be disabled if required.
Using the invite mechanism, setting up secure email communication is very easy.
Cons:
The recipient has to login to generate the password.
If the recipient forgets the portal password, the recipient cannot login and the password has to be reset.
The account for the recipient has to be pre-configured or the recipient has to be invited.
The gateway portal functionality must be accessible to external users.
With the One Time Password (OTP) mode, a recipient can be invited. Is this not insecure? What happens if the invite is intercepted?
Establishing a secure channel always hinges on how the first secret is exchanged. This applies to any encryption system. The most secure approach is to transmit that initial secret over a separate, trusted channel rather than through the same path as your encrypted content.
If you use one-time password mode, you can preconfigure a portal password for each recipient. You should then share that password with the recipient over a different channel, such as a phone call, secure messaging app, or in person, but not by email.
In practice, arranging a second channel or preconfiguring a unique password for every recipient can be inconvenient or impractical. For these situations, you can enable auto-invite mode.
When auto-invite mode is enabled and a recipient does not yet have a portal password, the system adds an invite link to the email. The recipient clicks this link and creates a password for their portal account. From that point on, they can generate the one-time password and open encrypted PDFs sent to them.
There is a security consideration to be aware of. If an attacker intercepts the email and clicks the invite link before the legitimate recipient, the attacker could set the password first. This would let the attacker generate the one-time password and read the first encrypted PDF intended for the recipient.
If this happens, the legitimate recipient will notice immediately when trying to sign in, because their chosen password will no longer work—they never got the chance to set it. Conversely, if the legitimate recipient clicks the invite link first and sets a password, any later clicks on the link (by an attacker or anyone else) will fail because the link is no longer valid after a password is set.
As a result, the attacker’s window of opportunity is limited to the period before the legitimate recipient sets the password. After a password is chosen, the invite link cannot be reused.
If you must be certain that the correct person set the password before sending sensitive information, send a separate email containing a simple keyword and then call the recipient to verify that keyword. Only proceed with sending sensitive content after the recipient confirms the keyword, which proves they are the one who completed the password setup.
Is HTML email supported by PDF Messenger?
HTML email support is available in CipherMail Pro; the Community Edition does not include this feature.