How does PGP differ from S/MIME?

  • 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?

    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.

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

    It appears that Maven artifacts in the Central repository are now being signed with PGP as well

    Isn't the other big thing that S/Mime doesn't encrypt everything whereas OpenPGP encrypts everything in a mail

    @David that is not true - S/MIME does encrypt "everything" - except of course envelope info i.e. Subject, From, etc

    @Conrad alright my bad

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

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM