PGP (Pretty Good Privacy)

PGP (Pretty Good Privacy)

Blog Credit: Trupti Thakur

Image Courtesy: Google

 

PGP

 

Pretty Good Privacy (PGP) is an encryption system used for both sending encrypted emails and encrypting sensitive files. Since its invention back in 1991, PGP has become the de facto standard for email security.

 

Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. Phil Zimmermann developed PGP in 1991.

PGP and similar software follow the OpenPGP, an open standard of PGP encryption software standard (RFC 4880) for encrypting and decrypting data. Modern versions of PGP are interoperable with GnuPG and other OpenPGP-compliant systems.

 

 

• PGP stands for Pretty Good Privacy (PGP) which is invented by Phil Zimmermann.
• PGP was designed to provide all four aspects of security, i.e., privacy, integrity, authentication, and non-repudiation in the sending of email.
• PGP uses a digital signature (a combination of hashing and public key encryption) to provide integrity, authentication, and non-repudiation. PGP uses a combination of secret key encryption and public key encryption to provide privacy. Therefore, we can say that the digital signature uses one hash function, one secret key, and two private-public key pairs.
• PGP is an open source and freely available software package for email security.
• PGP provides authentication through the use of Digital Signature.
• It provides confidentiality through the use of symmetric block encryption.
• It provides compression by using the ZIP algorithm, and EMAIL compatibility using the radix-64 encoding scheme.

 

Early history

Phil Zimmermann created the first version of PGP encryption in 1991. The name, “Pretty Good Privacy” was inspired by the name of a grocery store, “Ralph’s Pretty Good Grocery”, featured in radio host Garrison Keillor’s fictional town, Lake Wobegon. This first version included a symmetric-key algorithm that Zimmermann had designed himself, named BassOmatic after a Saturday Night Live sketch. Zimmermann had been a long-time anti-nuclear activist, and created PGP encryption so that similarly inclined people might securely use BBSs and securely store messages and files. No license fee was required for its non-commercial use, and the complete source code was included with all copies.

In a posting of June 5, 2001, entitled “PGP Marks 10th Anniversary”  Zimmermann describes the circumstances surrounding his release of PGP:

It was on this day in 1991 that I sent the first release of PGP to a couple of my friends for uploading to the Internet. First, I sent it to Allan Hoeltje, who posted it to Peacenet, an ISP that specialized in grassroots political organizations, mainly in the peace movement. Peacenet was accessible to political activists all over the world. Then, I uploaded it to Kelly Goen, who proceeded to upload it to a Usenet newsgroup that specialized in distributing source code. At my request, he marked the Usenet posting as “US only”. Kelly also uploaded it to many BBS systems around the country. I don’t recall if the postings to the Internet began on June 5th or 6th. It may be surprising to some that back in 1991, I did not yet know enough about Usenet newsgroups to realize that a “US only” tag was merely an advisory tag that had little real effect on how Usenet propagated newsgroup postings. I thought it actually controlled how Usenet routed the posting. But back then, I had no clue how to post anything on a newsgroup, and didn’t even have a clear idea what a newsgroup was.

PGP found its way onto the Internet and rapidly acquired a considerable following around the world. Users and supporters included dissidents in totalitarian countries (some affecting letters to Zimmermann have been published, some of which have been included in testimony before the US Congress), civil libertarians in other parts of the world (see Zimmermann’s published testimony in various hearings), and the ‘free communications’ activists who called themselves cypherpunks (who provided both publicity and distribution); decades later, CryptoParty activists did much the same via Twitter.

Criminal investigation

Shortly after its release, PGP encryption found its way outside the United States, and in February 1993 Zimmermann became the formal target of a criminal investigation by the US Government for “munitions export without a license”. At the time, cryptosystems using keys larger than 40 bits were considered munitions within the definition of the US export regulations; PGP has never used keys smaller than 128 bits, so it qualified at that time. Penalties for violation, if found guilty, were substantial. After several years, the investigation of Zimmermann was closed without filing criminal charges against him or anyone else.

Zimmermann challenged these regulations in an imaginative way. He published the entire source code of PGP in a hardback book,^] via MIT press, which was distributed and sold widely. Anybody wishing to build their own copy of PGP could cut off the covers, separate the pages, and scan them using an OCR program (or conceivably enter it as a type-in program if OCR software was not available), creating a set of source code text files. One could then build the application using the freely available GNU Computer collection. PGP would thus be available anywhere in the world. The claimed principle was simple: export of munitions—guns, bombs, planes, and software—was (and remains) restricted; but the export of books is protected by the First Amendment. The question was never tested in court with respect to PGP. In cases addressing other encryption software, however, two federal appeals courts have established the rule that cryptographic software source code is speech protected by the First Amendment (the  Ninth Circuit Court in Appeals in the Bernstein case and the Sixth Circuit court of Appeeals in the Junger Case)  US export regulations regarding cryptography remain in force, but were liberalized substantially throughout the late 1990s. Since 2000, compliance with the regulations is also much easier. PGP encryption no longer meets the definition of a non-exportable weapon, and can be exported internationally except to seven specific countries and a list of named groups and individuals (with whom substantially all US trade is prohibited under various US export controls).

PGP 3 and founding of PGP Inc.

During this turmoil, Zimmermann’s team worked on a new version of PGP encryption called PGP 3. This new version was to have considerable security improvements, including a new certificate structure that fixed small security flaws in the PGP 2.x certificates as well as permitting a certificate to include separate keys for signing and encryption. Furthermore, the experience with patent and export problems led them to eschew patents entirely. PGP 3 introduced the use of the CAST-128 (a.k.a. CAST5) symmetric key algorithm, and the DSA and EIGamal asymmetric key algorithms, all of which were unencumbered by patents.

After the Federal criminal investigation ended in 1996, Zimmermann and his team started a company to produce new versions of PGP encryption. They merged with Viacrypt (to whom Zimmermann had sold commercial rights and who had licensed RSA directly from RSADSI), which then changed its name to PGP Incorporated. The newly combined Viacrypt/PGP team started work on new versions of PGP encryption based on the PGP 3 system. Unlike PGP 2, which was an exclusively command line program, PGP 3 was designed from the start as a software library allowing users to work from a command line or inside a GUI environment. The original agreement between Viacrypt and the Zimmermann team had been that Viacrypt would have even-numbered versions and Zimmermann odd-numbered versions. Viacrypt, thus, created a new version (based on PGP 2) that they called PGP 4. To remove confusion about how it could be that PGP 3 was the successor to PGP 4, PGP 3 was renamed and released as PGP 5 in May 1997.

Network Associates acquisition

In December 1997, PGP Inc. was acquired by Network Associates, Inc. (“NAI”). Zimmermann and the PGP team became NAI employees. NAI was the first company to have a legal export strategy by publishing source code. Under NAI, the PGP team added disk encryption, desktop firewalls, intrusion detection, and IPsec VPNs to the PGP family. After the export regulation liberalizations of 2000 which no longer required publishing of source, NAI stopped releasing source code.

In early 2001, Zimmermann left NAI. He served as Chief Cryptographer for Hush Communications, who provide an OpenPGP-based e-mail service, Hushmail. He has also worked with Veridis and other companies. In October 2001, NAI announced that its PGP assets were for sale and that it was suspending further development of PGP encryption. The only remaining asset kept was the PGP E-Business Server (the original PGP Commandline version). In February 2002, NAI canceled all support for PGP products, with the exception of the renamed commandline product. NAI, now known as McAfee, continued to sell and support the product under the name McAfee E-Business Server until 2013.

PGP Corporation and Symantec

In August 2002, several ex-PGP team members formed a new company, PGP Corporation, and bought the PGP assets (except for the command line version) from NAI. The new company was funded by Rob Theis of Doll Capital Management (DCM) and Terry Garnett of Venrock Associates. PGP Corporation supported existing PGP users and honored NAI’s support contracts. Zimmermann served as a special advisor and consultant to PGP Corporation while continuing to run his own consulting company. In 2003, PGP Corporation created a new server-based product called PGP Universal. In mid-2004, PGP Corporation shipped its own command line version called PGP Command Line, which integrated with the other PGP Encryption Platform applications. In 2005, PGP Corporation made its first acquisition: the German software company Glück & Kanja Technology AG, which became PGP Deutschland AG. In 2010, PGP Corporation acquired Hamburg-based certificate authority TC TrustCenter and its parent company, ChosenSecurity, to form its PGP TrustCenter division.

After the 2002 purchase of NAI’s PGP assets, PGP Corporation offered worldwide PGP technical support from its offices in Draper, Utah; Offenbach, Germany; and Tokyo, Japan.

On April 29, 2010, Symantec Corp. announced that it would acquire PGP for $300 million with the intent of integrating it into its Enterprise Security Group. This acquisition was finalized and announced to the public on June 7, 2010. The source code of PGP Desktop 10 is available for peer review

Also in 2010, Intel Corporation acquired McAfee. In 2013, the McAfee E-Business Server was transferred to Software Diversified Services, which now sells, supports, and develops it under the name SDS E-Business Server.

For the enterprise, Townsend Security currently offers a commercial version of PGP for the IBM i and IBM z mainframe platforms. Townsend Security partnered with Network Associates in 2000 to create a compatible version of PGP for the IBM i platform. Townsend Security again ported PGP in 2008, this time to the IBM z mainframe. This version of PGP relies on a free z/OS encryption facility, which utilizes hardware acceleration. Software Diversified Services also offers a commercial version of PGP (SDS E-Business Server) for the IBM z mainframe.

In May 2018, a bug name EFAIL was discovered in certain implementations of PGP which from 2003 could reveal the plaintext contents of emails encrypted with it. The chosen mitigation for this vulnerability in PGP Desktop is to mandate the use SEIP protected packets in the ciphertext, which can lead to old emails or other encrypted objects to be no longer decryptable after upgrading to the software version that has the mitigation.

Broadcom

On August 9, 2019, Broadcom Inc. announced they would be acquiring the Enterprise Security software division of Symantec, which includes PGP Corpor

Following are the steps taken by PGP to create secure e-mail at the sender site:

• The e-mail message is hashed by using a hashing function to create a digest.
• The digest is then encrypted to form a signed digest by using the sender’s private key, and then signed digest is added to the original email message.
• The original message and signed digest are encrypted by using a one-time secret key created by the sender.
• The secret key is encrypted by using a receiver’s public key.
• Both the encrypted secret key and the encrypted combination of message and digest are sent together.

PGP at the Sender site (A)

Following are the steps taken to show how PGP uses hashing and a combination of three keys to generate the original message:

• The receiver receives the combination of encrypted secret key and message digest is received.
• The encrypted secret key is decrypted by using the receiver’s private key to get the one-time secret key.
• The secret key is then used to decrypt the combination of message and digest.
• The digest is decrypted by using the sender’s public key, and the original message is hashed by using a hash function to create a digest.
• Both the digests are compared if both of them are equal means that all the aspects of security are preserved.

PGP at the Receiver site (B)

PGP encryption uses a serial combination of hashing, data compression, symmetric key cryptography and finally public- key cryptography: each step uses one of the several supported algorithms. Each public key is bound to a username or an e-mail address. The first version of this system was generally known as a web of trust to contrast with the X 509 system. Which uses a hierarchical approach based on certificate authority and which was added to PGP implementation later. Current versions of PGP encryption include options through an automated key management server.

PGP fingerprint

A public key fingerprint is a shorter version of a public key. From a fingerprint, someone can validate the correct corresponding public key. A fingerprint like C3A6 5E46 7B54 77DF 3C4C 9790 4D22 B3CA 5B32 FF66 can be printed on a business card.

Compatibility

As PGP evolves, versions that support newer features and algorithms can create encrypted messages that older PGP systems cannot decrypt, even with a valid private key. Therefore, it is essential that partners in PGP communication understand each other’s capabilities or at least agree on PGP settings.

Confidentiality

PGP can be used to send messages confidentially. For this, PGP uses a hybrid cryptosystem by combining symmetric-key encryption and public-key encryption. The message is encrypted using a symmetric encryption algorithm, which requires a symmetric key generated by the sender. The symmetric key is used only once and is also called a session key. The message and its session key are sent to the receiver. The session key must be sent to the receiver so they know how to decrypt the message, but to protect it during transmission it is encrypted with the receiver’s public key. Only the private key belonging to the receiver can decrypt the session key, and use it to symmetrically decrypt the message.

Digital signatures

PGP supports message authentication and integrity checking. The latter is used to detect whether a message has been altered since it was completed (the message integrity property) and the former, to determine whether it was actually sent by the person or entity claimed to be the sender (a  digital signature). Because the content is encrypted, any changes in the message will fail the decryption with the appropriate key. The sender uses PGP to create a digital signature for the message with either the RSA or DSA algorithms. To do so, PGP computes a hash (also called a message digest) from the plaintext and then creates the digital signature from that hash using the sender’s private key.

Web of trust

Both when encrypting messages and when verifying signatures, it is critical that the public key used to send messages to someone or some entity actually does ‘belong’ to the intended recipient. Simply downloading a public key from somewhere is not a reliable assurance of that association; deliberate (or accidental) impersonation is possible. From its first version, PGP has always included provisions for distributing user’s public keys in an ‘Identity Certification’, which is also constructed cryptographically so that any tampering (or accidental garble) is readily detectable. However, merely making a certificate that is impossible to modify without being detected is insufficient; this can prevent corruption only after the certificate has been created, not before. Users must also ensure by some means that the public key in a certificate actually does belong to the person or entity claiming it. A given public key (or more specifically, information binding a user name to a key) may be digitally signed by a third-party user to attest to the association between someone (actually a user name) and the key. There are several levels of confidence that can be included in such signatures. Although many programs read and write this information, few (if any) include this level of certification when calculating whether to trust a key.

The web of trust protocol was first described by Phil Zimmermann in 1992, in the manual for PGP version 2.0:

As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.

The web of trust mechanism has advantages over a centrally managed public key infrastructure scheme such as that used by S/MIME but has not been universally used. Users have to be willing to accept certificates and check their validity manually or have to simply accept them. No satisfactory solution has been found for the underlying problem.

Certificates

 

In the (more recent) OpenPGP specification, trust signatures can be used to support creation of Certificate Authorities. A trust signature indicates both that the key belongs to its claimed owner and that the owner of the key is trustworthy to sign other keys at one level below their own. A level 0 signature is comparable to a web of trust signature since only the validity of the key is certified. A level 1 signature is similar to the trust one has in a certificate authority because a key signed to level 1 is able to issue an unlimited number of level 0 signatures. A level 2 signature is highly analogous to the trust assumption users must rely on whenever they use the default certificate authority list (like those included in web browsers); it allows the owner of the key to make other keys certificate authorities.

PGP versions have always included a way to cancel (‘revoke’) public key certificates. A lost or compromised private key will require this if communication security is to be retained by that user. This is, more or less, equivalent to the certificate revocation lists of centralized PKI schemes. Recent PGP versions have also supported certificate expiration dates.

The problem of correctly identifying a public key as belonging to a particular user is not unique to PGP. All public key/private key cryptosystems have the same problem, even if in slightly different guises, and no fully satisfactory solution is known. PGP’s original scheme at least leaves the decision as to whether or not to use its endorsement/vetting system to the user, while most other PKI schemes do not, requiring instead that every certificate attested to by a central certificate authority be accepted as correct.

Security quality

To the best of publicly available information, there is no known method that will allow a person or group to break PGP encryption by cryptographic, or computational means. Indeed, in 1995, cryptographer Bruce Schneier characterized an early version as being “the closest you’re likely to get to military-grade encryption.  Early versions of PGP have been found to have theoretical vulnerabilities and so current versions are recommended. In addition to protecting data in transit over a network, PGP encryption can also be used to protect data in long-term data storage such as disk files. These long-term storage options are also known as data at rest, i.e. data stored, not in transit.

The cryptographic security of PGP encryption depends on the assumption that the algorithms used are unbreakable by direct cryptanalysis with current equipment and techniques.

In the original version, the RSA algorithm was used to encrypt session keys. RSA’s security depends upon the one-way function nature of mathematical integer factoring. Similarly, the symmetric key algorithm used in PGP version 2 was IDEA, which might at some point in the future be found to have previously undetected cryptanalytic flaws. Specific instances of current PGP or IDEA insecurities (if they exist) are not publicly known. As current versions of PGP have added additional encryption algorithms, their cryptographic vulnerability varies with the algorithm used. However, none of the algorithms in current use are publicly known to have cryptanalytic weaknesses.

New versions of PGP are released periodically and vulnerabilities fixed by developers as they come to light. Any agency wanting to read PGP messages would probably use easier means than standard cryptanalysis, e.g. rubber-hose cryptanalysis or black-bag (e.g. installing some form of trojan horse or keystroke logging software/hardware on the target computer to capture encrypted keyrings and their passwords). The FBI has already used this attack against PGP in its investigations. However, any such vulnerabilities apply not just to PGP but to any conventional encryption software.

In 2003, an incident involving seized Psion PDAs belonging to members of the Red Brigade indicated that neither the Italian Police nor the FBI were able to decrypt PGP-encrypted files stored on them.

A second incident in December 2006, (see In re Boucher), involving US customs agents who seized laptop PC that allegedly contained child pronography, indicates that US government agencies find it “nearly impossible” to access PGP-encrypted files. Additionally, a magistrate judge ruling on the case in November 2007 has stated that forcing the suspect to reveal his PGP passphrase would violate his Fifth Amendment rights i.e. a suspect’s constitutional right not to incriminate himself. The Fifth Amendment issue was opened again as the government appealed the case, after which a federal district judge ordered the defendant to provide the key.

Evidence suggests that as of 2007, British Police investigators are unable to break PGP,  so instead have resorted to using RIPA legislation to demand the passwords/keys. In November 2009 a British citizen was convicted under RIPA legislation and jailed for nine months for refusing to provide police investigators with encryption keys to PGP-encrypted files.

PGP as a cryptosystem has been criticized for complexity of the standard, implementation and very low usability of the user interface including by recognized figures in cryptography research. It uses an ineffective serialization format for storage of both keys and encrypted data, which resulted in signature-spamming attacks on public keys of prominent developers of GNU Privacy Guard. Backwards compatibility of the OpenPGP standard results in usage of relatively weak default choices of cryptographic primitives (CAST5 cipher, CFB mode, S2K password hashing). The standard has been also criticized for leaking metadata, usage of long-term keys and lack of forward secrecy. Popular end-user implementations have suffered from various signature-striping, cipher downgrade and metadata leakage vulnerabilities which have been attributed to the complexity of the standard.

ation.

 

Disadvantages of PGP Encryption

• The Administration is difficult: The different versions of PGP complicate the administration.
• Compatibility issues: Both the sender and the receiver must have compatible versions of PGP. For example, if you encrypt an email by using PGP with one of the encryption technique, the receiver has a different version of PGP which cannot read the data.
• Complexity: PGP is a complex technique. Other security schemes use symmetric encryption that uses one key or asymmetric encryption that uses two different keys. PGP uses a hybrid approach that implements symmetric encryption with two keys. PGP is more complex, and it is less familiar than the traditional symmetric or asymmetric methods.
• No Recovery: Computer administrators face the problems of losing their passwords. In such situations, an administrator should use a special program to retrieve passwords. For example, a technician has physical access to a PC which can be used to retrieve a password. However, PGP does not offer such a special program for recovery; encryption methods are very strong so, it does not retrieve the forgotten passwords results in lost messages or lost files.

 

Blog By: Trupti Thakur