March 12, 2008

Know your PGP implementation

Filed under: Security — Tags: , , , , — martin @ 8:53 am

Being an expert for all sorts of application layer encryption, I currently work on a call for tenders for a client who wants to implement centralized e-mail encryption for his 30k-something users.

While the X.509 standard for e-mail, S/MIME, can safely be considered a generally available standard nowadays, it’s pretty scary to see that certain vendors of encryption software for the enterprise have a very sketchy understanding of what PGP encrypted communication looks like in the real world. They seem to believe that PGP isn’t actually that relevant, while on the other hand, real people and real corporations have been using PGP to protect their (trade) secrets long before those PGP vendors had even been founded.

There are currently three major methods for PGP encryption of e-mail in the wild. One of these is an actual internet standard, one is a customary procedure, and the other, oh well…:


PGP/MIME is the only official standard for PGP e-mail encryption. It is defined in RFC 3156 (“MIME Security with OpenPGP”). Put simply, PGP/MIME takes the entire MIME encoded message and wraps another MIME layer around it. This “outer” layer contains either the encrypted message or it contains the original MIME encoded message plus an attachment containing the detached signature. PGP/MIME is widely supported by products that integrate e-mail and PGP encryption.

2) “PGP-Inline”

PGP-Inline is a retroactively applied name for the legacy method for PGP encryption that was used in the early days of PGP, before the introduction of PGP/MIME. It does not constitute an actual standard. Instead, there only is a certain behaviour that users have learned to expect from PGP-Inline messages.

A PGP-Inline message contains the message text in ASCII-armored form, either encrypted or clearsigned. It is evident that MIME multipart/alternative e-mails that contain the message text in both text and HTML form can not be handled very well in such an environment.

Attachments are encrypted each on their own. The file example.pdf is attached as example.pdf.asc, example.pdf.gpg or example.pdf.pgp, depending on implementation and user preference. As far as I can tell, there is no accepted standard for signed attachments in PGP-Inline. A well-behaved implementation of PGP-Inline can be observed in the Enigmail plugin for the Thunderbird MUA when PGP/MIME is turned off. This implementation uses detached signatures for signing attachments.

Vendors usually refer to RFC 4880 (“OpenPGP Message Format”) when being asked about PGP-Inline. While having a certain relevance, this RFC does not mention anything related to E-Mail. It is therefore in fact unsuitable as a guideline for the proper behaviour of PGP-Inline. Don’t get fooled by RFC mumbo-jumbo.

3) “Partitioned PGP”

Partitioned PGP can be described as “PGP-Inline with cloaked filenames”. Long after PGP/MIME had been widely accepted as a standard, the PGP corporation introduced their “Universal” product line. PGP Universal extends the commonpractice PGP-Inline method by concealing the filename. Our file example.pdf from the earlier example gets renamed to Attachment.pgp. The original filename is hidden inside the ciphertext in the “Literal Data Packet (Tag 11)” as described by RFC 4880.

Partitioned PGP carries over the original MIME Content-Type tags of Attachments by storing them inside proprietary MIME headers:

X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/html; charset="iso-8859-1"

To my best of knowledge, these extensions are not publicly documented. During my research I have only come across an archived e-mail from a developer at the PGP corporation that outlines the technique. This particular e-mail is my only point of reference when it comes to the technical details of partitioned PGP.

Restoration of these headers and of the original filename has been implemented by all relevant commercial vendors, most likely through a small amount of reverse engineering. The same applies for the HTML part of multipart/alternative messages, which PGP Universal attaches as PGPexch.htm. A skilled developer can easily understand the HTML part’s encoding by closely examining encrypted messages from PGP Universal.


While PGP/MIME will usually be supported by most communication partners, PGP-Inline still has lots of relevance as the lowest common denominator. As such, it should be as interoperable as possible, despite the lack of a hard and fast specification. Users that have no integration of PGP into their e-mail software will resort to exactly those techniques that are usually considered “PGP-Inline”: Encrypt the message, and encrypt each attachment on its own. This is where we all came from, before PGP/MIME.

The PGP corporation claim that their “Partitioned PGP” is identical with PGP-Inline. This is technically true only if a PGP-Inline implementation’s default mode of operation is to extract the original filename. If this is not the case, “Partitioned PGP” yields decrypted files that are named Attachment, Attachment1 and so on, which offer no clue about the original file name. While experienced UNIX users can easily determine the file type using the file command, typical end users have no proper means of handling the situation.

The PGP corporation may have their reasons for extending PGP-Inline in such a way. Cloaking the file name is fairly reasonable indeed. However, PGP/MIME has always been doing exactly the same by wrapping the MIME encoded message with its attachments into an opaque PGP layer. This was standardized and available long before the PGP corporation had even been founded.

I find it not very hard to believe that the manoeuver of extending PGP-Inline in a proprietary way is an attempt to create market share by forcing a de-facto standard into existence. With a big name such as “PGP”, everything seems possible. Also, if the PGP corporation really were that serious about leakage of potential confidential information, they should have taken care of the message headers as well. Instead, they chose to create an amount of incompatibility, that is covered by some RFC and appears to be subtle, but in fact irritates users and support staff on the receiving side in the worst possible way.

There is no doubt that the PGP corporation employs honest cryptography specialists that are a lot smarter than I will ever be, no matter how much I learn. Their marketing and product management departments, however, have created an enormous amount of distrust in me. On one hand, they’ll promise you heaven and earth with their big name and their global presence. On the other hand, they seem to be completely disconnected from the PGP community and appear to not have an idea of how cryptography has always been used in real, day-to-day production environments. Which is a real pity.

March 24, 2005


Filed under: Internet — Tags: , — martin @ 11:02 pm

Das sind MIME-encoded Words laut RFC 1522 2047:


Codiert werden die z.B. so:

echo "äöü.exe" |
perl -MMIME::Words=:all -ne 'chomp;$_=encode_mimeword($_,B,"utf-8");print"$_\n"'

oder defensiver:

echo "äöü.exe" |
perl -MMIME::Words=:all -pe 'chomp;$_=encode_mimewords($_);$_.="\n"'

Decodiert werden sie so:

echo "=?UTF-8?B?5Pb8LmV4ZQ==?=" |
perl -MMIME::Words=:all -pe '$_=decode_mimewords($_)'

Create a free website or blog at WordPress.com.