Skip to main content

PGP and S/MIME Protocol

Both PGP and S/MIME protocols are used for authentication and privacy of messages over internet.

S/MIME protocol refers to Secure/Multipurpose Internet Mail Extensions which has been incorporated in the various main exchange software, incl. Outlook, Thunderbird & others And also incorporated in all major browsers (chrome, Mozilla, IE and others). S/MIME is based on IETF standards and defined in RFC 5751.
  RFC 5751 defined S/MIME as "S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures), and data confidentiality (using encryption). As a supplementary service, S/MIME provides for message compression."

PGP known as Pretty Good Privacy, is a data encryption and decryption computer program that provides cryptographic privacy and authentication for data communication. PGP is often used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. It was created by Phil Zimmermann in 1991.
PGP and similar software follow the OpenPGP standard (RFC 4880) for encrypting and decrypting data.

PGP user has the ability to give its public key to another user directly or the 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 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.

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.




Popular posts from this blog

Is APNIC policy of Members Voting Rights doing the Justice with NIRs and Corresponding Countries

APNIC (the Asia Pacific Network Information Centre) is the regional Internet address registry (RIR) for the Asia-Pacific region, service 56 economies, including India, Bangladesh, China, Australia, Japan and others. APNIC is one of the world's five RIRs and is part of the Number Resource Organization (NRO). As of date, the following 7 NIRs (National Internet Registries) are registered with APNIC for serving the local community a b c -- NIR Serving Economy Member under each NIR d APJII (ID) Indonesia 2916 e CNNIC (CN) China  1399 IRINN (IN) India  3368 JPNIC (JP) Japan   474 KISA (KR) Korea Not Available TWNIC (TW) Taiwan   299 VNNIC (VN) Vietnam   624 APNIC Membership is classified into 7 tiers depending on the IP holding by each member. Each membership tier has voting rights. These voting rights play a crucial role in governance and policies matt

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a