79

Is S/MIME an abstracted system for general MIME type encryption, whereas PGP is more for email? Why would I want to choose one over the other, or can I use both at the same time?

Paŭlo Ebermann
  • 2,467
  • 19
  • 20
Tyler Gillies
  • 893
  • 1
  • 7
  • 5
  • 4
    In addition to the other answers (i.e. the trust model is different) it may be worth noting that PGP originally (and still supports) implmenting the signature within a SMTP header - while S/MIME implements it as an attachment - which has a lot of relevance for processing gateways / bridges. – symcbean Oct 05 '11 at 11:50

6 Answers6

79

Summary: S/MIME and PGP both provide "secure emailing" but use distinct encodings, formats, user tools, and key distribution models.


S/MIME builds over MIME and CMS. MIME is a standard way of putting arbitrary data into emails, with a "type" (an explicit indication of what the data is supposed to mean) and gazillions of encoding rules and other interoperability details. CMS means "Cryptographic Message Syntax": it is a binary format for encrypting and signing data. CMS relies on X.509 certificates for public key distribution. X.509 was designed to support top-down hierarchical PKI: a small number of "root certification authorities" issue (i.e. sign) certificates for many users (or possibly intermediate CA); a user certificate contains his name (in an email context, his email address) and his public key, and is signed by a CA. Someone wanting to send an email to Bob will use Bob's certificate to get his public key (needed to encrypt the email, so that only Bob will be able to read it); verifying the signature on Bob's certificate is a way to make sure that the binding is genuine, i.e. this is really Bob's public key, not someone else's public key.

PGP is actually an implementation of the OpenPGP standard (historically, OpenPGP was defined as a way to standardize what the pre-existing PGP software did, but there now are other implementations, in particular the free opensource GnuPG). OpenPGP defines its own encryption methods (similar in functionality to CMS) and encoding formats, in particular an encoding layer called "ASCII Armor" which allows binary data to travel unscathed in emails (but you can also mix MIME and OpenPGP). For public key distribution, OpenPGP relies on Web of Trust: you can view that as a decentralized PKI where everybody is a potential CA. The security foundation of WoT is redundancy: you can trust a public key because it has been signed by many people (the idea being that if an attacker "cannot fool everybody for a long time").

Theoretically, in an enterprise context, WoT does not work well; the X.509 hierarchical PKI is more appropriate, because it can be made to match the decisional structure of the envisioned companies, whereas WoT relies on employees making their own security policy decisions.

In practice, although most emailing softwares already implement S/MIME (even Outlook Express has implemented S/MIME for about one decade), the certificate enrollment process is complex with interactions with external entities, and requires some manual interventions. OpenPGP support usually requires adding a plugin, but that plugin comes with all that is needed to manage keys. The Web of Trust is not really used: people exchange their public keys and ensure binding over another medium (e.g. spelling out the "key fingerprint" -- a hash value of the key -- over the phone). Then people keep a copy of the public keys of the people they usually exchange emails with (in the PGP "keyring"), which ensures appropriate security and no hassle. When I need to exchange secure emails with customers, I use PGP that way.

OpenPGP is also used, as a signature format, for other non-email tasks, such as digitally signing software packages in some Linux distributions (at least Debian and Ubuntu do that).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • It appears that Maven artifacts in the [Central repository](http://maven.apache.org/guides/mini/guide-central-repository-upload.html) are now being signed with PGP as well – senecaso Oct 07 '11 at 16:56
  • “In practice, although …, *the certificate enrollment process is complex with interactions with external entities, and requires some manual interventions*.” Is there more information about this? From what I learn, if a company uses its own (internal) root CA, no third-party should be required. I haven’t try this myself though. – Franklin Yu May 24 '18 at 14:06
14

All the IPs are designed to facilitate the secure and smooth flow of data transmission in networking. S/MIME and PGP are both protocols used for authentication and privacy to messages over the internet. PGP, stands for Pretty Good Privacy, is a data encryption and decryption computer program that offers cryptographic privacy and authentication for Internet data transmission. PGP is widely used for signing, encrypting and decrypting electronic data to maximize the security issues of data exchange. The protocol S/MIME refers to Secure/Multipurpose Internet Mail Extensions. S/MIME is recently included in the latest versions of the web browsers from renowned software companies like Microsoft and Netscape and has also been broadly accepted by many vendors in all around the world. It is also driven as a standard for public key encryption and signing of MIME data. S/MIME is based on an IETF standard and most commonly defined in RFCs documents. S/MIME provides the authentication, message integrity and non-repudiation of origin and data security services for electronic data transmission applications.

S/MIME is very closely similar to PGP and its predecessors. S/MIME is derived from the PKCS #7 data format for the messages, and the X.509v3 format for certificates. PGP encryption uses a serial combination of hashing, data compression, symmetric-key cryptography, and public-key cryptography.

While using PGP, one user has the ability to give directly a public key to another user or the second user can obtain the public key from the first user. PGP does not mandate a policy for creating trust and hence each user is free to decide the length of trust in the received keys. With the S/MIME, the sender or receiver does not rely on exchanging keys in advance and share a common certifier on which both can rely.

S/MIME is considered superior to PGP from an administrative perspective because of its strength, support for centralized key management through X.509 certificate servers and extensive industry support. PGP is more complicated from an end-user perspective, because it requires additional plug-ins or downloads to operate. S/MIME protocol allows most vendors to send and receive encrypted email without using additional software.

S/MIME is convenient because of secure transformation of all applications like spreadsheets, graphics, presentations, movies etc., but PGP was originated to address the security concerns of plain e-mail or text messages. S/MIME is also highly affordable in terms of its cost.

Summary: S/MIME and PGP protocols use different formats for key exchange. PGP depends upon each user’s key exchange S/MIME uses hierarchically validated certifier for key exchange. PGP was developed to address the security issues of plain text messages. But S/MIME is designed to secure all kinds of attachments/data files. Nowadays, S/MIME is known to dominate the secure electronic industry because it is incorporated into many commercial e-mail packages. S/MIME products are more readily available, and for lower prices, than PGP products.

cpast
  • 7,223
  • 1
  • 29
  • 35
nikoo28
  • 241
  • 2
  • 4
  • 3
    I just want to point out that there's nothing stopping you from distributing S/MIME certificates the same way you distribute PGP hashes. They'd just have to be included whole, or linked to, and then trusted by the recipient the same as PGP users have to decide to trust. – SilverbackNet Mar 15 '14 at 09:06
  • 2
    Please clarify the statement, "S/MIME products are cheaply available than for PGP." Looks like a grammar issue is present, and cited sources would be nice. – Dave Jarvis Sep 03 '14 at 04:08
  • 2
    I use PGP for free. the core package [GnuPG](https://www.gnupg.org/donate/index.html) is free, the [GPG Suite](https://gpgtools.org/donate.html) was free, and there are many free [publicly accessible key-servers](https://sks-keyservers.net/status/) supporting the infrastructure. As individuals, we should support these projects, so they don't have to rely too much on governments or corporations. – code_monk Jan 24 '16 at 20:35
  • This answer may haven been copied from [this article](http://www.differencebetween.net/technology/software-technology/difference-between-pgp-and-smime/) because that article seems written at 2011. If so, please cite that article. – Franklin Yu Jan 03 '18 at 21:28
10

If you "read between the lines" at the wikipedia entries you may come closer to an answer. S/MIME:

is a standard for public key encryption and signing of MIME data

where MIME is the standard for transporting more than simple ASCII text over the original SMTP mail system. You integrate S/MIME with your digital certificates, bought (thus stamped and certified by a CA) or locally produced (thus self signed).

As for PGP I would describe it as an outside application handling encryption/signing that may integrate transparently with your email application and provide such services. Each user gets his/her public-private key pair and uses this for all operations.

As pointed by @chris, the trust models upon which each operates are slightly different but IMHO this doesn't make one or the other less secure.

In practice the two solutions have more or less interchangeable keys. You may use a PGP issued key pair with your mail application's S/MIME and (I think) vice-versa. Somebody please correct me on this last one...

The main deciding factor for me would be cost:

PGP: software solution matching your needs + software renewal costs + administrative costs for key exchanges

compared to:

S/MIME: administrative cost of running a certificate server for locally produced certs + administrative costs for public key distribution OR the cost of buying certs from a CA + renewal fees

Don't forget that most email clients already support S/MIME "out of the box", reducing original costs in this case.

George
  • 2,813
  • 2
  • 23
  • 39
  • 7
    There is free and open software for PGP for most mail clients I believe. For Apple Mail (gpgtools) and Thunderbird (enigmail) anyway, and for the commandline on all platforms (gnupg) – chris Oct 05 '11 at 09:39
  • 2
    Absolutely! The cost comes only if we are talking about enterprise deployment. – George Oct 05 '11 at 10:25
  • 1
    @chris none of the smartphone mail clients i've ever used have PGP plugins available, but they all support S/MIME. – Abhi Beckert Aug 24 '13 at 01:26
  • 2
    @chris: We have about 50% volume over smartphones/tablets (iOS) so the presence of S/MIME and the absence of PGP sorta seals the deal. Just contrasting reality with your `all platforms` comment. – DeepSpace101 Oct 10 '13 at 15:43
  • @AbhiBeckert This may be a new development, but Android phones can use the GPL3 [APG](https://play.google.com/store/apps/details?id=org.thialfihar.android.apg&hl=en), which integrates with (for example) K-9 mail. – Sparhawk Aug 08 '14 at 06:52
  • @Sparhawk Link dead. Maybe APG is gone. – Franklin Yu May 24 '18 at 14:28
  • @FranklinYu APG has since been forked into [OpenKeychain](https://www.openkeychain.org/faq/#what-is-the-relationship-between-apg-and-openkeychain). I'm using this now, which works well. – Sparhawk May 25 '18 at 00:21
1

S/MIME depends on the SSL PKI: you have an SSL certificate with your public key, and the fact that it is signed by a certificate authority (CA) "proves" it is really your key. PGP on the other hand does not have a PKI: you check if a person's public key really belongs to him by having him say so while showing has passport (key signing party) or trusting they key because many other peoples have done this check and signed his key.

With the recent developments in CA security, I'd say there is a very big reason not to trust S/MIME :-) While the PGP "web of trust" model is not as simple in use as S/MIME, it provides a lot more security if you make the effort.

Both systems end up using asymmetric encryption by the way, they really differ in how trust in a public key is established.

chris
  • 3,000
  • 14
  • 22
  • The public-private key pair has nothing to do with SSL except from the fact that it uses the same technologies. You may deploy a Public Key Infrastructure (PKI) just for your S/MIME needs independently of any SSL/TLS application – George Oct 05 '11 at 07:34
  • Well it uses the same PKI, meaning the same Certificate Authorities right? And the same roots that you trust by default? – chris Oct 05 '11 at 07:37
  • 5
    Your statement of "there is a very big reason not to trust S/MIME" should be mitigated. Indeed, there has been cases of stolen root certificate and Certificate Authority not doing a good job in issuing their certificates. Nevertheless, the PKI provides a more managed environment, that are designed to deal with those risks. Furthermore, the infrastructure makes possible the wide usage of the technology. How would you communicate with ppl you don't know with PGP? Relying on known authorities makes this possible with S/MIME. In concl, S/MIME indeed brings new risks, but controls risks. – M'vy Oct 05 '11 at 07:48
  • 4
    In my opinion, PKI doesn't control risks at all. There are *so* many roots in my keychain per default, who says I can trust the government of China, the US or Estonia? The whole system is broken, one leak CA means compromise of all the trust. And there are 175 roots in my keychain, let alone intermediate CAs! – chris Oct 05 '11 at 09:33
  • 2
    And if you see the level of security measures some CAs apparently get away with (DigiNotar)... makes you wonder, how many have silently been compromised? – chris Oct 05 '11 at 09:34
  • @M'vy, you ask how to communicate with someone in PGP that you dont know.. Cant you just look up their key on a public key server, and assuming it has been signed by enough people or the right people, you can trust it and begin communication? How does it work with S/MIME? AFAIK there are no key servers, so I cant simply look someone up to send them an encrypted email. I suppose I could send him an email requesting that he replies to me with an encrypted email so that we exchange certificates, but that seems a little clunky, no? I'm hazy on the details though, so I'm probably wrong... – senecaso Oct 07 '11 at 17:05
  • @senecaso, as stated in the answer, S/MIME depends on PKI. So if someone emails you their certificate, and it is signed by a CA you trust, then the key belongs to the user. The problem is in the trust assumption about the CA... – chris Oct 07 '11 at 20:01
  • 2
    @senecaso Were you looking for [S/MIME key servers](http://wiki.cacert.org/KeyServers)? – Franklin Yu Jan 03 '18 at 21:43
  • @chris If you doubt PKI as a whole, guess you don’t trust TLS either? – Franklin Yu May 24 '18 at 14:34
0

A few years later, but I believe it should be important. In Europe, digital signatures have to use CMS because of the defined extensions (CAdES, XAdES etc).

Therefore, PGP is useless in that field and S/MIME is the only way to go.

0

Adding some perspective from 2018: efail happened. It adds some interesting perspective, since at first both OpenPGP and S/MIME were vulnerable. But OpenPGP is mostly fixed due to all important implementations making the MDC (modification detection check) mandatory. The problem for S/MIME though is, there is nothing like MDC. Thus it remains vulnerable. From what I understand that is an important argument to favor the decentralized OpenPGP over S/MIME.

foss
  • 101
  • 1
  • EFAIL was possible thanks to mail clients allowing active content. And PGP was even more affected than S/MIME since with PGP encrypted parts may be whenever in the message text, thus allowing injection of html or js from non-encrypted parts, while with S/MIME secured parts are properly delimited by MIME boundaries. – Outtruder Sep 13 '19 at 08:37