Are PGP and GPG compatible

S / MIME vs. OpenPGP: A decision aid

Management and knowledge

Email encryption

By Christian Kirsch, Offenbach

Discussions about the advantages and disadvantages of the mail encryption protocols S / MIME and OpenPGP often turn into a war of faith. Practical considerations may well be the focus when choosing one of the systems - but there is no favorite when it comes to security.

S / MIME users like to claim that (Open) PGP is insecure; OpenPGP fans like to complain about the insecurity of S / MIME. However, such statements are mostly based on a lack of know-how. If you look closely, it turns out that both protocols meet current security requirements equally. In any case, they ultimately only deal with the "packaging" of encrypted or signed messages. Both concepts are based on recognized, secure cryptographic procedures. In all cases, weaknesses found in the past were due to implementation errors by the manufacturer.

The availability of client software or plug-ins for existing solutions is no longer a priority selection criterion, since both worlds support the common applications (you should also evaluate the front-ends in your own environment anyway). Nevertheless, S / MIME and OpenPGP differ in some basic things, so that there can be practical reasons that make one or the other protocol more attractive. To understand the differences between the two standards, it is helpful to briefly discuss how they came about.

(Open) PGP: The Origin

PGP stands for "Pretty Good Privacy". In 1991 Phil Zimmermann, then a student at MIT, "invented" PGP. Zimmermann wanted to create workable, easy-to-use software that was based on the anarchic structure of the Internet. Because he released the program as freeware and disclosed the source code, PGP quickly found wide acceptance in the Internet community. The inadequate usability of the first command line programs improved over the years with the appearance of Windows software and plug-ins for mail clients, so that even less tech-savvy users can use the software today.

A few years later, Phil Zimmermann founded PGP Inc .; the company was founded in late 1997 by Network Associates (NAI), who still own PGP copyrights to this day. Although the product is still available as freeware for private, non-commercial use, commercial users, universities and authorities have to buy the software - contrary to popular opinion.

The great success of PGP ensured that the underlying protocol was gradually written down in Internet standards, so-called RFCs (Request for Comments, [7, 8]). RFC 1991 appeared in August 1996 and defines the PGP message format. NAI and various independent cryptographers began to develop the OpenPGP standard [4]. OpenPGP is backwards compatible with old PGP versions, but offers a wider range of algorithms and functions. The OpenPGP standard was passed in November 1998 as RFC 2440. NAI wants to develop its products compatible with the OpenPGP standard in the future.

S / MIMEOpenPGPPGP 2.6.xPGP 5.x
Asymmetric algorithms (encryption)RSARSA, ElGamal, not yet specified: Elliptic Curve, Diffie-Hellman (X9.42)RSARSA, ElGamal (referred to here as Diffie-Hellman)
Asymmetric algorithms (signature)RSARSA, DSA, not yet specified: ElGamal, ECDSARSARSA, DSA
Symmetrical AlgorithmsTripleDES, DES, RC2TripleDES, IDEA, CAST5, Blowfish, SAFER-SK128, Twofish, Not yet specified: DES / SK, des. AES (Rijndael)IDEATripleDES, IDEA, CAST5
Hash algorithmsMD5, SHA-1MD5, SHA-1, RIPE-MD / 160, MD2, Not yet specified: Double-width SHA, TIGER / 192, HAVALMD5MD5, SHA-1

Comparison of algorithms used

Since the adoption of the OpenPGP standard, various manufacturers have brought their own implementations onto the market. For example, Glück & Kanja Software AG offers a Public Key Infrastructure (PKI) based on OpenPGP (a freeware version is also available here for private users).

The "Open" in OpenPGP stands for an open standard, not for open source. The German Unix User Group e.V. (GUUG) developed however funded by Federal Ministry of Economics and Technology (BMWi) with some partners GNU Privacy Guard (GnuPG, [5]), a command line oriented open source implementation of the OpenPGP standard. At least outside of the Unix world, there is currently a lack of user-friendly front ends.

The S / MIME story

The Secure Multipurpose Internet Mail Extensions, S / MIME for short, were developed in 1995 by a consortium of manufacturers [2], but it was not until version 2 that they became widely used. S / MIME Version 2 is essentially based on RFC 2311 (Message Specification) and RFC 2312 (Certificate Handling) as well as the Public Key Cryptography Standards (PKCS) RFC 2314 (PKCS # 10) and RFC 2315 (PKCS # 7). However, these RFCs are purely informative, i.e. the The Internet Engineering Taskforce (IETF) has not made S / MIME v2 the standard.

Version 3 was passed by the IETF in July 1999 [3] and is essentially based on RFC2630 (Cryptographic Message Syntax, CMS), RFC 2633 (Message Specification), RFC 2632 (Certificate Handling) and RFC 2631 (Diffie-Hellman Key Agreement Method) . Currently, however, most products are still based on version 2, as the integration of S / MIME v3 has not yet been completed by a number of manufacturers.

The S / MIME concept provides a hierarchical structure and requires a trustworthy authority as a certificate authority (see [1]). Since, in contrast to PGP, several manufacturers implemented S / MIME from the start, there were initially major problems with the interoperability of the individual products. These seem to have been largely resolved in the meantime (see also the S / MIME Interoperability Center on [2]).

Message exchange format

S / MIME and OpenPGP are not compatible, i.e. users of both worlds cannot exchange signed or encrypted messages. Even if both use the same mathematical algorithms (for example RSA, Triple-DES and MD5), OpenPGP and S / MIME products cannot "understand" each other. While there are several reasons for this, the most important one is certainly the different message exchange format.

MIME is a widely used standard for formatting Internet e-mails, based on RFC 822 (ARPA Internet Text Messages). S / MIME uses RFC 1847 (Security Multiparts for MIME), which extends the existing MIME structure with cryptographic elements so that a certain MIME section, for example the text of an e-mail or a file attachment, can be signed or encrypted.

However, this method is not limited to S / MIME. PGP / MIME (RFC 2015), an extension to the earlier PGP standard, also uses RFC 1847 to encrypt and sign emails and file attachments. An update is in work as a draft IETF-OpenPGP-MIME (see [3]).

Key (bunch) formats

The key and keyring formats of the two standards also follow different concepts. S / MIME uses X.509 certificates for formatting public keys, which only allow a single signature under the public key to prove its validity. Usually a certification authority (CA) creates this signature. An X.509 certificate can only contain a public key, a user ID and a signature.

In addition to the signature, an X.509 certificate also contains other parts, such as a distinguished name and a serial number, which is assigned by the CA. The e-mail address is not a mandatory part of an X.509 certificate and can be found in optional version 3 extensions. Nowadays, however, it is advisable to store the owner's e-mail address in the certificate, as this property is searched for when e-mails are encrypted and a mail client may otherwise not be able to automatically assign the certificate to the recipient of a message.

Although both procedures are based on the same principles, X.509 is called a certificate, but OpenPGP is a public key. The most important difference to X.509 certificates is that an OpenPGP key can contain any number of signatures. In addition, each key is basically "self-signed", i.e. signed with the associated secret key (self-certificate). The identifier of an OpenPGP key is not a serial number assigned by a CA, but a so-called key ID, the part of a hash value about the key.


Unlike X.509 certificates, PGP keys can carry multiple certificates and user IDs.

An OpenPGP key can consist of several keys, one primary and several secondary ones. The primary key can have multiple user IDs that can have multiple signatures (certificates). These possibilities make OpenPGP keys much more flexible than X.509 certificates. This then generally looks like this:

  • primary key (public key of a signature algorithm)
    • one or more user IDs
    • one or more certificate (s)
  • one or more secondary keys (public keys)

A specific OpenPGP key could therefore contain:

  • Primary key: DSA (signature)
    • User ID: Jon Doe
    • signed by: primary key (own certificate)
    • signed by: ACME Certificate Authority
    • signed by: TC TrustCenter
       
    • User ID: Jon Doe
    • signed by: primary key (own certificate)
  • Secondary key: ElGamal (encryption)
  • Secondary key: RSA (encryption and signature)

Trust and hierarchies

X.509 uses a strict hierarchical system for the certification of public keys. A Certificate Authority (CA) is at the top of the certification hierarchy and signs the keys of all participants within the Public Key Infrastructure (PKI) either directly or via sub-CAs. The individual users have their own key and the public CA key and can thus check the validity of unknown certificates.

In contrast to this, OpenPGP uses the so-called Web of Trust in the classic model, an anarchic approach that simulates the trust structure of the disordered Internet community. While the Web of Trust has many advantages over an X.509 hierarchy for private use, it is unsuitable for companies. In contrast to S / MIME, OpenPGP implementations allow a free choice of the PKI model. With a strictly hierarchical certification chain, even large companies are already successfully using OpenPGP (detailed information in OpenPGP as PKI for companies, KES 2000/5, p. 82).

Public key infrastructure

The different types of public key infrastructures also relate to the history of the two standards. For a central, publicly available system for distributing keys, OpenPGP usually uses so-called HTTP key servers. The (Open) PGP community has in the pgp.net network [6] as well as with the servers of the providers of OpenPGP software (e.g. www.keyserver.de) a worldwide - more or less well synchronized - "PKI" has already been implemented. A comparable infrastructure does not exist in the X.509 world to this day.

However, these servers are nothing more than databases that have an HTTP interface and allow users to deliver keys or to inquire about certain search criteria. The response from the server is an HTML page that can be evaluated either manually via a web browser or automatically with the encryption program. HTTP keyservers are quick and easy to set up and require little maintenance.

X.509 certificates are stored in X.500-compliant LDAP directory services, such as the Microsoft Active Directory, the Novell NDS or the Siemens Dir.X Meta Directory. LDAP directory services are a better solution for storing certificates than HTTP keyservers. A look at the Microsoft Active Directory makes this clear: Modern companies are trying to consolidate their data sources. The Active Directory offers a central place to store various user "properties" such as user groups, passwords, telephone numbers and certificates. Directory services are also easier to replicate and are therefore currently available in the various branches of a company.

If you use an HTTP keyserver instead of an LDAP directory service to store the certificates, at least two data sources must be maintained when an employee joins or leaves the company. In addition, a separate replication mechanism as well as concepts for availability, backup, etc. are required for the HTTP keyserver.

Although an IETF group is currently working on a standard for storing OpenPGP keys in LDAP directory services, no recommendation has yet been passed. In practice, however, there are already two possible solutions: On the one hand, Network Associates offer keyserver software that offers keys via LDAP. This is essentially an "HTTP key server" with a few extra search functions that communicates via a different protocol (LDAP), but is not to be regarded as a general directory service. And on the other hand it enables CryptoEx Security Suite to process OpenPGP keys with S / MIME keys together in any LDAP directory.

Making LDAP directory services accessible to external partners, on the other hand, is problematic: On the one hand, this requires a copy of the LDAP server in a security zone of the firewall system (DMZ). On the other hand, all communication partners have to open the LDAP port on the firewall so that the users can receive the certificates - and LDAP is not proxy-capable.

OpenPGP offers a good alternative here because of its long experience with the Internet community. It is advisable to set up an HTTP keyserver in the DMZ, which acts as an HTTP relay for LDAP, i.e. uses the LDAP directory service as a data source and therefore does not have to be maintained separately. Keyservers answer by default on port 11371, but can also be configured without problems on port 80, which should not be blocked on most firewalls; Proxies are then also possible with HTTP.


In order to make LDAP directories accessible to external partners, an HTTP key server is recommended as a "relay station" in the DMZ when using OpenPGP.

Revoked keys

S / MIME and OpenPGP also go different ways in dealing with revoked keys: OpenPGP stores revoked keys with the active keys in the same keyserver or directory service. The revocation is attached to the key as a specially shaped signature. When checking a signature, a suitably configured client can fetch the key from the server using the key ID and check its validity locally. Such a check requires an online connection, but is always up-to-date.

S / MIME, on the other hand, uses Certificate Revocation Lists (CRLs), which manage all blocked keys in a black list. The clients load the list or a list update at regular intervals in order to have the current revocation lists available. In this case, the clients do not have to maintain an online connection to the server, but on the one hand they do not always have the latest information, on the other hand the list of CRLs is constantly growing and has to be downloaded regularly and saved on each client. In addition, as negative lists, CRLs can only state which key invalid are, but not whether a key valid is. In addition, as the number of external partners increases, the amount of CRL increases and is difficult to manage.

The Online Certificate Status Protocol (OCSP) offers an alternative to CRLs in S / MIME. OCSP works in a similar way to the procedure outlined for OpenPGP. To check a certificate, the certificate identifier is sent to a so-called OCSP responder, which sends a signed message with the certificate status good, revoked or unknown returns. The difference to OpenPGP is that the CA checks the certificate in its own context, while the validity calculation with OpenPGP takes place in the client. With OCSP, S / MIME comes a big step closer to the OpenPGP concept, even if the two methods are again incompatible on this point. Since OCSP is a very new protocol, most manufacturers do not yet have any finished implementations available.

Operating environment

If e-mail security is only to be guaranteed on Windows-based systems, both standards are equally suitable. However, if Unix, Linux or Palm PDAs are integrated into the concept, the use of OpenPGP is recommended, as this is available on more platforms. According to evaluations by Glück & Kanja Software AG, OpenPGP is currently the more frequently used standard with a share of around 60 to 70 percent of all encrypted e-mails.

The OpenPGP standard also allows almost any information to be encrypted: from e-mails to files and hard drives to IP traffic.S / MIME means Secure MIME and is therefore just suitable for e-mails. However, X.509 certificates can be used for almost all forms of encryption and digital signature.

Conclusion

S / MIME and OpenPGP both have the same task: encrypting and signing data. While there are some important differences, ultimately none of the standards offers an overall advantage over the other.

While a few years ago it looked as if S / MIME would gain the upper hand in the long term, many companies seem to be opting for an OpenPGP PKI due to its proven practicality and the considerably simpler and more flexible structure. So the race is not over yet. Because internally, too, not even the big players in the industry seem to agree: Microsoft's product development officially relies on S / MIME, while the security bulletins of the Microsoft Product Security Notification Service are regularly authenticated by OpenPGP signatures.

Christian Kirsch is Product Manager for Security Products at Glück & Kanja Software AG, Offenbach am Main, a company of Biodata Information Technology AG.

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 1/2001, page 60


Back to content