Saturday, April 21, 2007

Comparative Analysis of OpenPGP and S/MIME


Both S/MIME and OpenPGP are end to end security mechanisms that facilitate secure email transmission. S/MIME and OpenPGP are competing technologies that operate in much the same way. This document aims to analyze the difference between the two technologies, and to describe the costs and benefits of each.

PGP is the common name for a security methodology first introduced by Philip Zimmermann. PGP is an acronym for "Pretty Good Privacy". The IETF standard for this methodology is referred to as OpenPGP. OpenPGP is described by RFC 2440.

S/MIME is short for Secure/Multipurpose Internet Mail Extensions. It was first developed by RSA Data Security, Inc. The S/MIME standard is described by RFC 3851. Not all versions of the technology are part of the standard.



PGP was first developed by Philip Zimmermann in 1991. The source code of the project was distributed with the program and a team of developers emerged around the project. In 1996, Philip and his team formed PGP Inc. PGP Inc. created versions three, four and five of PGP.

In 1997, the technology branched in two directions. First, in July, amidst growing concerns over algorithms with licensing difficulties, Philip and a subset of the team proposed an "Unencumbered PGP" to the IETF for standards consideration [WIKIP-OP]. The proposal was accepted and given the formal name OpenPGP..

In December of 1997, PGP Inc. was aquired by Network Associates, Inc (NAI). Philip left NAI in 2001 to join Hush Communications, an OpenPGP based mail service provider. In 2002, NAI sold PGP assets to a group of original PGP team members excluding Philip [WIKIP-OP]. The newly formed company was named PGP Corporation, and it is still in business selling PGP based technolgogies. Philip serves in an advisory role for the company.

OpenPGP is still on the standards track (as of this writing), and is being actively developed. One primary implementation of the standard has emerged from the GNU project, named GNU Privacy Guard (GnuPG).


S/MIME was first developed by the RSA Data Security Inc. in collaboration with other private organizations [IMC]. Early versions of the technology were not part of the standards track, primarily due to patent restrictions on the RSA encryption algorithm used in the technology. Version three of the technology was the first to be part of a standard in 1999. However it was defined by RFC 2633 which has since been obsoleted by S/MIME version 3.1 described by RFC 3851. RFC 3851 is the current standard and the topic of this document.

One Distinct Difference

OpenPGP is a general purpose encryption methodology. As stated by the OpenPGP RFC it is "data integrity services for messages and data files." S/MIME is specifically designed for MIME-encapsulated data. Generally this means email, but technically it could mean any technology supporting MIME encoding. From the S/MIME RFC, "S/MIME provides a consistent way to send and receive secure MIME data."

This is an important distinction. OpenPGP can and does have practical application outside of the context of Internet messaging. For example:

  • A user may choose to encrypt their entire home directory to protect data on disk. All documents stored inside the directory would be encrypted and only accesible with the corresponding private key.
  • A user could encrypt a single file, then use delivery mechanisms other than email, such as FTP, to transfer the file to its destination.

Products exist for both the commerical PGP specification and the OpenPGP specification. Additionally GnuPG can be used as a library by third party programs to enable encryption and decryption for many different scenerios.


Both OpenPGP and S/MIME function in much the same way. We will ignore the fact, for now, that OpenPGP has use outside of email and focus on its merits as an email encryption methodology. Both OpenPGP and S/MIME are end-to-end encryption methodologies. In other words, the data is encrypted at the origination site, transmitted in a standard networking envelope (the traffic patterns are not protected) and decrypted at the destination site. Additionally, both use public-private key type encryption.


The following list describes the common path taken by an email message transformed by either technology:

  1. Compose message
  2. Encrypt/sign message with private key
    • Sign message
    • Encrypt data (requires recipients public key)
    • Sign message and encrypt data (requires recipients public key)
  3. Transmit message
  4. Decrypt/verify message with senders public key
    • Verify signed message
    • Decrypt data (requires recipients private key)
    • Verify message and decrypt data (requires recipients private key)
  5. Read message

Encryption and Signing Process

There are many details involved in describing the encryption and signing process. For the purposes of this document we will explore where they are different in the process. For simplicity, we will compare S/MIME to OpenPGP, not OpenPGP/MIME (see below), and we will show situations where encyption and signing are occuring.

OpenPGP Encryption & Signing

  1. Plaintext message created (M)
  2. M hashed (H)
  3. H encrypted (EH)
  4. EH and M concatenated (EHM)
  5. EHM compressed (Z)
  6. Z symettrically encrypted with session key (ZS)
  7. Session key encrypted with recipient's public key (SP)
  8. ZS and SP concatenated (EM)
  9. Encrypted and signed message, EM, complete

S/MIME Encryption & Signing

OpenPGP is assembled as shown with a couple of concatenations of parts. S/MIME divides these parts into separate subtype MIME entities. These separate entities can encapsulate each other and be applied in any order because they all result in MIME encapuslated output. Following is a listing of the relevant "Content Types" according to the RFC:

  1. Data
  2. SignedData
  3. EnvelopedData
  4. CompressedData

S/MIME prior to version 3.1 did not provide compression. Compression was added to 3.1 as a MIME type. It is not clear how well current S/MIME client programs support compression . The prevailing community information indicates that compression is not well supported. Presumably, if compression were implemented, OpenPGP and S/MIME would map roughly in the following way:

OpenPGP StepS/MIME Content Type
  • Plaintext message created (M)
  • M hashed (H)
  • H encrypted (EH)
  • EH and M concatenated (EHM)
  • EHM compressed (Z)
CompressedData (see above)
  • Z symettrically encrypted with session key (ZS)
  • Session key encrypted with recipient's public key (SP)
  • ZS and SP concatenated (EM)
  • Encrypted and signed message, EM, complete

Transmission Format

OpenPGP has two message formats: OpenPGP and OpenPGP/MIME. OpenPGP, by default, offers a non-mime-encapsulated message transmission. In other words it is equivalent to a standard plain text email without any attachements. OpenPGP/MIME is similar in formatting to S/MIME. Both use MIME encapsulation for the transmission of data and signtures. Following are actual transmissions of encrypted and signed data (just signed or just encrypted would have similar characteristics):

OpenPGP - Signed & Encrypted

Subject: Test Sign and Enc
Content-Type: text/plain;

Charset: ISO-8859-1
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla -

...[segment snipped for readability]...

OpenPGP/MIME - Signed & Encrypted

Subject: test PGP/MIME
Content-Type: multipart/encrypted;

This is an OpenPGP/MIME encrypted message (RFC 2440 and 3156)
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla -

...[segment snipped for readability]...


S/MIME - Signed & Encrypted

Subject: Testing S/MIME Enc
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
Content-Description: S/MIME Encrypted Message

...[segment snipped for readability]...


Both technologies share a number of algorithms. The following table represents each function and its corresponding set of technologies as described by their respective RFCs (shared algorithms have added emphasis):

Public Key RSA, Diffie-Hellman, DSA, Elgamal, Elliptic Curve, ECDSA RSA, Diffie-Hellman, DSA
Symmetric Key AES, Triple-DES, IDEA, CAST5, Blowfish, SAFER-SK128, DES/SK, AES, Triple-DES, RC2
Compression ZLIB, ZIP ZLIB (as described in related RFC 3274)
Hash MD5, SHA-1, RIPE-MD/160, Double-Width SHA, MD2, TIGER, HAVAL MD5, SHA-1

Web of Trust and Public Key Infrastructure

OpenPGP and S/MIME both provide mechanisms for authenticating parties. OpenPGP relies on a concept called a "Web of Trust." It is essentially a distributed peer validating service. The concept was introduced by Philip Zimmermann. It works much like social networking. Person A, Alice, sends her public key to person B, Bob. Bob adds Alice's public key to his key ring and optionally indicates his level of trust in Alice's key. Over time the trust endorsements are calculated and the net effect is a decentralized "web of trust."

S/MIME relies on Certificate Authorities (CA) to authenticate parties. This is similar in nature to the way SSL certificates are issued for serving secure web sites. Various models are used by CA's to authenticate a person. Generally it is similar to authenticating with a government agency. A person must provide several forms of identification.

Both OpenPGP and S/MIME allow you to use them relatively untrusted. In other words, you may generate or obtain valid private and public keys that are useable but are "untrusted". This is a good thing for getting started quickly with each technology. For example if one wanted to communicate securely with someone who had never used either technology the recipient could quickly be up and running enabling them to communicate in a timely manner.

The primary difference between a Web of Trust and a Public Key Infrastructure is a matter of trust. Do you trust a decentralized peer group or a centralized organization?


Both OpenPGP and S/MIME are well supported across many platforms and applications. For the purposes of this document, a test was conducted on the following platforms and applications:

Mac OS X

Evolution, and Outlook were considered, for the purposes of this paper, to be the most entrenched mail applications on each platform. This is not a completely fair assertion for the Linux platform as many good email clients exist for that platform. However, Evolution is very similar to Outlook which increase its likely usage in business settings.

All tested software listed above were fairly easily installed and configured. It is worth noting that all tested Mail User Agent's (MUA) support S/MIME by default and all MUA's required a plugin to support OpenPGP. With the exception of Evolution which came preconfigured for both technologies.

Problems only occurred with one tested program, Gpg4win's Outlook plugin. Specifically, Outlook with Gpg4win could not encrypt plaintext formatted email messages. Working from a bug report found online it was discovered that by composing HTML formatted email messages worked as expected. For Outlook PGP integration's PGP Desktop may be a better choice.

A few notes from the tested products:

  • S/MIME integration was very easy for all mail clients
  • Enigmail makes OpenPGP integration very easy for Thunderbird.
  • Evolution could use an integrated GPG key management window. External applications exist for this purpose but an integrated window, similar to Enigmail, would improve usability.
  • Similar criticism applies to An integrated key management window would improve usability.
  • The easiest configuration was S/MIME for Though most S/MIME configurations were simple, was completely configured by adding the S/MIME key to the system keyring, simply by double-clicking the key file.
  • Thunderbird should be noted. It was the only cross platform mail application. Additionally it was easily configured to use both OpenPGP and S/MIME. Certainly Enigmail makes it the easiest OpenGPG implementation.


The largest difference between OpenPGP and S/MIME is the ability for OpenPGP to encrypt a variety of data types not limited to MIME encoded data types. This gives OpenPGP a decided edge over S/MIME in the way of versatility.

For large data streams, OpenPGP provides more efficient compression. Though compression is available in the S/MIME specification it is implemented as an MIME container. In other words, the contents to be compressed have already been encoded per the MIME specification, usually Base64. Base64 actually grows the data by about 137% [WIKIP-B64]. In contrast, OpenPGP compresses the original plaintext, and optionally the signature prior to encryption or any type of encoding.

Both OpenPGP and S/MIME use industry standard encryption algorithms. Neither technology is more secure than the other, barring esoteric arguments. Some would rank each technology based on the trust model used. However, the security aspect of each trust model is subjective.

The trust models used for each technology are very different in philosophy. In practice, neither method is more difficult to use than the other. It is arguable that S/MIME is more attractive due to its similarities to SSL certificate distribution, a model already trusted by most web users implicitly.

S/MIME has an advantage when it comes to implementation. All mail clients tested came with S/MIME support built in. As a result, the barriers to entry for a new user are lower. Generating an S/MIME certificate required a bit more effort than OpenPGP. So the time commitment for setting up each initially is similar. However the zero-footprint install may be attractive to those managing many workstations.

How would one choose between the two technologies? Many factors play a part in this decision. The following table provides a visual representation of the pros and cons of each technology:

Versatility + -
Space Efficiency + -
Security + +
Trust Model + +
Implementation - +

No comments: