Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
2  
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 5 '11 at 11:50

4 Answers 4

up vote 25 down vote accepted

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).

share|improve this answer
    
It appears that Maven artifacts in the Central repository are now being signed with PGP as well –  senecaso Oct 7 '11 at 16:56

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.

share|improve this answer
    
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 –  Georgios Oct 5 '11 at 7:34
    
Well it uses the same PKI, meaning the same Certificate Authorities right? And the same roots that you trust by default? –  chris Oct 5 '11 at 7:37
3  
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 5 '11 at 7:48
2  
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 5 '11 at 9:33
1  
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 5 '11 at 9:34

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.

share|improve this answer
3  
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 5 '11 at 9:39
    
Absolutely! The cost comes only if we are talking about enterprise deployment. –  Georgios Oct 5 '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 1:26
    
@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, which integrates with (for example) K-9 mail. –  Sparhawk Aug 8 at 6:52

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 cheaply available than for PGP.

share|improve this answer
    
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 at 9:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.