Hubbry Logo
Pretty Good PrivacyPretty Good PrivacyMain
Open search
Pretty Good Privacy
Community hub
Pretty Good Privacy
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Pretty Good Privacy
Pretty Good Privacy
Pretty Good Privacy
View on Wikipedia
from Wikipedia

Pretty Good Privacy
Original authors
DeveloperBroadcom Inc.
Initial release1991; 34 years ago (1991)
Stable release
11.4.0 Maintenance Pack 2 / May 23, 2023; 2 years ago (2023-05-23)[2]
Written inC
Operating systemmacOS, Windows[3]
Standards
  • OpenPGP: RFC 4880, 5581, 6637, 9580
  • PGP/MIME: RFC 2015, 3156
TypeEncryption software
LicenseCommercial proprietary software
Websitewww.broadcom.com/products/advanced-threat-protection/encryption Edit this on Wikidata

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.[4]

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

The OpenPGP standard has received criticism for its long-lived keys and the difficulty in learning it,[6] as well as the Efail security vulnerability that previously arose when select e-mail programs used OpenPGP with S/MIME.[7][8] The new OpenPGP standard (RFC 9580) has also been criticised by the maintainer of GnuPG Werner Koch, who in response created his own specification LibrePGP.[9] This response was dividing, with some embracing his alternative specification,[10] and others considering it to be insecure.[11]

Design

[edit]
How PGP encryption works visually

PGP encryption uses a serial combination of hashing, data compression, symmetric-key cryptography, and finally public-key cryptography; each step uses one of 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 implementations later. Current versions of PGP encryption include options through an automated key management server.

PGP fingerprint

[edit]

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 such as C3A6 5E46 7B54 77DF 3C4C 9790 4D22 B3CA 5B32 FF66 can be printed on a business card.[12][13]

Compatibility

[edit]

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.[14]

Confidentiality

[edit]

PGP can be used to send messages confidentially.[15] 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

[edit]

PGP supports message authentication through digital signatures to verify whether a message was actually sent by the person or entity claimed to be the sender. The sender uses PGP to create a digital signature for the message with one of several supported public-key algorithms. To do so, PGP computes a hash, or digest, from the plaintext and then creates the digital signature from that hash using the sender's private key.

Web of trust

[edit]
Main article: 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

[edit]
Main article: Public key certificate

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 centralised 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

[edit]

To the best of publicly available information, there is no known method which 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."[16] Early versions of PGP have been found to have theoretical vulnerabilities and so current versions are recommended.[17] 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.[18] 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 cryptanalysis (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[19][20] 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.[21][unreliable source?]

A second incident in December 2006, (see In re Boucher), involving US customs agents who seized a laptop PC that allegedly contained child pornography, 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.[22][23] 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.[24]

Evidence suggests that as of 2007, British police investigators are unable to break PGP,[25] 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.[26]

PGP as a cryptosystem has been criticized for complexity of the standard, implementation and very low usability of the user interface[27] including by recognized figures in cryptography research.[28][29] 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).[30] 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.[31]

History

[edit]

Early history

[edit]

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.[32] 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",[33] 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

[edit]

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. In 1995, he published the entire source code of PGP in a hardback book,[34] 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 Compiler 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 of Appeals in the Bernstein case and the Sixth Circuit Court of Appeals 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[35] (with whom substantially all US trade is prohibited under various US export controls).

The criminal investigation was dropped in 1996.[36]

PGP 3 and founding of PGP Inc.

[edit]

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 ElGamal 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

[edit]

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.[37]

Asset split

[edit]

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.[38][39]

McAfee

[edit]

NAI, now known as McAfee, continued to sell and support the commandline product under the name McAfee E-Business Server until 2013.[40] In 2010, Intel Corporation acquired McAfee. In 2013, the McAfee E-Business Server was transferred to Software Diversified Services (SDS), which now sells, supports, and develops it under the name SDS E-Business Server.[40][38]

For the enterprise, Townsend Security currently[when?] 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. SDS also offers a commercial version of PGP (SDS E-Business Server) for the IBM z mainframe.

PGP Corporation

[edit]

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,[41] which became PGP Deutschland AG.[42] In 2010, PGP Corporation acquired Hamburg-based certificate authority TC TrustCenter and its parent company, ChosenSecurity, to form its PGP TrustCenter[43] division.[44]

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.

Symantec
[edit]

On April 29, 2010, Symantec Corp. announced that it would acquire PGP Corporation for $300 million with the intent of integrating it into its Enterprise Security Group.[45] 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.[46]

In May 2018, a bug named EFAIL was discovered in certain implementations of PGP which from 2003 could reveal the plaintext contents of emails encrypted with it.[47][48] 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.[49]

Broadcom
[edit]

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

PGP Corporation encryption applications

[edit]
This section describes commercial programs available from PGP Corporation. For information on other programs compatible with the OpenPGP specification, see External links below.

While originally used primarily for encrypting the contents of e-mail messages and attachments from a desktop client, PGP products have been diversified since 2002 into a set of encryption applications that can be managed by an optional central policy server. PGP encryption applications include e-mails and attachments, digital signatures, full disk encryption, file and folder security, protection for IM sessions, batch file transfer encryption, and protection for files and folders stored on network servers and, more recently, encrypted or signed HTTP request/responses by means of a client-side (Enigform) and a server-side (mod openpgp) module. There is also a WordPress plugin available, called wp-enigform-authentication, that takes advantage of the session management features of Enigform with mod_openpgp.

The PGP Desktop 9.x family includes PGP Desktop Email, PGP Whole Disk Encryption, and PGP NetShare. Additionally, a number of Desktop bundles are also available. Depending on the application, the products feature desktop e-mail, digital signatures, IM security, whole disk encryption, file, and folder security, encrypted self-extracting archives, and secure shredding of deleted files. Capabilities are licensed in different ways depending on the features required.

The PGP Universal Server 2.x management console handles centralized deployment, security policy, policy enforcement, key management, and reporting. It is used for automated e-mail encryption in the gateway and manages PGP Desktop 9.x clients. In addition to its local keyserver, PGP Universal Server works with the PGP public keyserver—called the PGP Global Directory—to find recipient keys. It has the capability of delivering e-mail securely when no recipient key is found via a secure HTTPS browser session.

With PGP Desktop 9.x managed by PGP Universal Server 2.x, first released in 2005, all PGP encryption applications are based on a new proxy-based architecture. These newer versions of PGP software eliminate the use of e-mail plug-ins and insulate the user from changes to other desktop applications. All desktop and server operations are now based on security policies and operate in an automated fashion. The PGP Universal server automates the creation, management, and expiration of keys, sharing these keys among all PGP encryption applications.

The Symantec PGP platform has now undergone a rename. PGP Desktop is now known as Symantec Encryption Desktop (SED), and the PGP Universal Server is now known as Symantec Encryption Management Server (SEMS). The current shipping versions are Symantec Encryption Desktop 10.3.0 (Windows and macOS platforms) and Symantec Encryption Server 3.3.2.

Also available are PGP Command-Line, which enables command line-based encryption and signing of information for storage, transfer, and backup, as well as the PGP Support Package for BlackBerry which enables RIM BlackBerry devices to enjoy sender-to-recipient messaging encryption.

New versions of PGP applications use both OpenPGP and the S/MIME, allowing communications with any user of a NIST specified standard.[50]

OpenPGP

[edit]

Within PGP Inc., there was still concern surrounding patent issues. RSADSI was challenging the continuation of the Viacrypt RSA license to the newly merged firm. The company adopted an informal internal standard that they called "Unencumbered PGP" which would "use no algorithm with licensing difficulties". Because of PGP encryption's importance worldwide, many wanted to write their own software that would interoperate with PGP 5. Zimmermann became convinced that an open standard for PGP encryption was critical for them and for the cryptographic community as a whole. In July 1997, PGP Inc. proposed to the IETF that there be a standard called OpenPGP. They gave the IETF permission to use the name OpenPGP to describe this new standard as well as any program that supported the standard. The IETF accepted the proposal and started the OpenPGP Working Group.[citation needed]

OpenPGP is on the Internet Standards Track and is under active development. Many e-mail clients provide OpenPGP-compliant email security as described in RFC 3156. The current specification is RFC 9580 (July 2024), the successor to RFC 4880. RFC 9580 specifies a suite of required algorithms consisting of X25519, Ed25519, SHA2-256 and AES-128. In addition to these algorithms, the standard recommends X448, Ed448, SHA2-384, SHA2-512 and AES-256. Beyond these, many other algorithms are supported.

  • PGP
    • RFC 1991 PGP Message Exchange Formats (obsolete)[51]
  • OpenPGP
    • RFC 2440 OpenPGP Message Format (obsolete)[51]
    • RFC 4880 OpenPGP Message Format (obsolete)
    • RFC 5581 The Camellia Cipher in OpenPGP (obsolete)
    • RFC 6637 Elliptic Curve Cryptography (ECC) in OpenPGP (obsolete)
    • RFC 9580 OpenPGP
  • PGP/MIME
    • RFC 2015 MIME Security with Pretty Good Privacy (PGP)
    • RFC 3156 MIME Security with OpenPGP

OpenPGP's encryption can ensure the secure delivery of files and messages, as well as provide verification of who created or sent the message using a process called digital signing. The open source office suite LibreOffice implemented document signing with OpenPGP as of version 5.4.0 on Linux.[52] Using OpenPGP for communication requires participation by both the sender and recipient. OpenPGP can also be used to secure sensitive files when they are stored in vulnerable places like mobile devices or in the cloud.[53] In late 2023, a schism occurred in the OpenPGP world: IETF's OpenPGP working group decided to choose a "crypto-refresh" update strategy for the RFC 4880 specification, rather than a more gradual "4880bis" path preferred by Werner Koch, author of GnuPG. As a result, Koch took his draft, now abandoned by the workgroup, and forked it into a "LibrePGP" specification.[9]

Implementations

[edit]

The Free Software Foundation has developed its own OpenPGP-compliant software suite called GNU Privacy Guard, freely available together with all source code under the GNU General Public License and is maintained separately from several graphical user interfaces that interact with the GnuPG library for encryption, decryption, and signing functions (see KGPG, Seahorse, MacGPG).[undue weight? – discuss] Several other vendors[specify] have also developed OpenPGP-compliant software.

The development of an open source OpenPGP-compliant library, OpenPGP.js, written in JavaScript and supported by the Horizon 2020 Framework Programme of the European Union,[54] has allowed web-based applications to use PGP encryption in the web browser.

PGP keys are supported in Mozilla Thunderbird (Built-in in version 78 onwards on PC,[55] and with the OpenKeychain app as of version 9 on Android[56]), GitHub,[57] and GitLab.[58]

Limitations

[edit]

With the advancement of cryptography, parts of PGP and OpenPGP have been criticized for being dated:

  • The long length of PGP public keys, caused by the use of RSA and additional data other than the actual cryptographic key[59]
  • Lack of forward secrecy[59]
  • Use of outdated algorithms by default in several implementations[59]
  • Difficulty for the users to comprehend and poor usability[29]
  • Lack of ubiquity[29]

In October 2017, the ROCA vulnerability was announced, which affects RSA keys generated by buggy Infineon firmware used on Yubikey 4 tokens, often used with OpenPGP. Many published PGP keys were found to be susceptible.[60] Yubico offers free replacement of affected tokens.[61]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Pretty Good Privacy

View on Grokipedia
from Grokipedia
Pretty Good Privacy (PGP) is a computer program for data encryption and decryption that enables cryptographic privacy and authentication for electronic communications, such as email, using a combination of symmetric-key and public-key cryptography. Developed by Phil Zimmermann in 1991 as freeware amid concerns over government surveillance, PGP was designed to allow individuals to secure their messages without relying on trusted third parties for key management. Its public release prompted a U.S. government criminal investigation for alleged violations of export control laws, which classified strong encryption software as munitions, though charges were ultimately dropped in 1996 after years of scrutiny. PGP evolved into the basis for the OpenPGP standard, formalized in RFC 4880 and later updated in RFC 9580, which specifies interoperable formats for encrypted messages, digital signatures, and key management, influencing implementations like GNU Privacy Guard (GnuPG). While praised for democratizing access to robust encryption and enabling secure communication for dissidents and privacy advocates, PGP has faced criticism for usability challenges, long-lived keys vulnerable to compromise, and vulnerabilities like Efail in certain implementations, though its core algorithms remain secure against known attacks when properly used.

Technical Design

Core Algorithms and Hybrid Cryptosystem

Pretty Good Privacy (PGP) employs a that integrates for bulk data with for secure , enabling efficient protection of messages, files, and emails. The process begins with optional compression of the using algorithms like ZIP, followed by computation of a digest via a for integrity verification or signing. A random symmetric is then generated and used to encrypt the compressed data in cipher feedback (CFB) mode. This is asymmetrically encrypted using the recipient's public key and attached to the encrypted payload, allowing only the private key holder to recover the and decrypt the message. This design balances the computational efficiency of symmetric ciphers for large payloads with the key distribution advantages of asymmetric methods, avoiding the need to securely transmit long-term symmetric keys. In its foundational implementation by in 1991, PGP version 1.0 utilized RSA for public-key encryption and signatures, paired with an initial symmetric cipher later replaced by IDEA due to vulnerabilities in the prototype Bass-O-Matic algorithm. Hashing relied on for digests. Subsequent versions and the OpenPGP standard (RFC 4880, published November 2007) expanded support to multiple algorithms to enhance flexibility and security. Symmetric ciphers include IDEA (128-bit), TripleDES (168-bit), CAST5 (128-bit), Blowfish (variable), and AES (128-, 192-, or 256-bit keys), with AES recommended for modern use due to its resistance to known attacks. Public-key algorithms encompass RSA (typically 1024-4096 bits for encrypt-or-sign), ElGamal (encrypt-only), and DSA (sign-only), alongside elliptic curve variants like ECDSA and ECDH in extensions. Hash algorithms feature (now deprecated), , SHA-256, SHA-384, and SHA-512, selected based on security strength; implementations must support SHA-256 or stronger for new signatures to mitigate collision vulnerabilities in older hashes. The hybrid structure ensures while permitting upgrades, as algorithm preferences are negotiated via key flags and user configurations.

Key Management and Web of Trust

In OpenPGP implementations of Pretty Good Privacy (PGP), key management begins with the generation of asymmetric key pairs, consisting of a public key for and verification and a corresponding private key for decryption and signing, using algorithms such as Ed25519 for signatures and X25519 for , as mandated by the standard. Primary keys serve for , while optional subkeys handle specific operations like signing or to compartmentalize risks if compromised. Private keys are encrypted with a user and stored securely, with key material formatted in packets including creation time, algorithm identifiers, and multiprecision integers or octet strings for parameters. Public keys are distributed via transferable public key packets that bundle the primary key, user identities, subkeys, and associated signatures, enabling exchange through email, keyservers, or direct file transfer without a central registry. Key identification relies on 8-byte key IDs or longer fingerprints (20 bytes for version 4 keys, 32 for version 6) derived from SHA-256 hashes, facilitating lookup while mitigating collision risks. Revocation is managed through dedicated signatures—key revocation (type 0x20) or subkey revocation (type 0x28)—issued by the key owner or a pre-designated revoker, often prepared in advance as revocation certificates specifying reasons like compromise or supersession; these signatures propagate to invalidate the key for future validations upon distribution. The model provides decentralized validation of key authenticity and identity bindings, eschewing hierarchical certificate authorities in favor of user-generated certification s (e.g., positive certification type 0x13) that attest to the linkage between a public key and a user ID. Users sign keys of personally verified individuals, forming transitive chains where trust propagates through interconnected s; software then computes key validity by evaluating path lengths, counts, and assigned trust levels from subpackets (levels 0–2, with depth and amount indicators up to 255). Owner trust assignments—ranging from undefined to ultimate in tools like GnuPG—gauge the reliability of a keyholder as a certifier, enabling marginal, full, or strong validity ratings based on the strongest sets of introducers. This model supports resilient, assurance but relies on active participation and for effective , with trust computations remaining implementation-specific to accommodate varying policies.

Digital Signatures and Message Authentication

Digital signatures in Pretty Good Privacy (PGP) enable verification of a message's origin and detection of any alterations, leveraging asymmetric to bind the content to the sender's identity. The process begins with the sender computing a cryptographic hash of the using algorithms such as SHA-256 or SHA-512, producing a fixed-size digest that represents the data's integrity. This hash is then encrypted with the sender's private key via a public-key algorithm like RSA or DSA, yielding the digital , which is appended to the as a signature packet in the OpenPGP format. Upon receipt, the verifier recomputes the hash of the message and decrypts the using the sender's corresponding public key. If the decrypted value matches the recomputed hash, the is valid, confirming both authenticity—since only the private key holder could have produced it—and , as any modification would alter the hash. PGP supports various types, including binary documents (type 0x00) for and text documents (type 0x01) that normalize line endings before hashing to handle email-specific formatting. Detached signatures allow separate verification of files without embedding, while inline signatures integrate directly into messages, often combined with compression and in a sign-then-encrypt to obscure content from intermediaries. Message authentication in PGP relies primarily on these digital signatures rather than symmetric message authentication codes (MACs), providing alongside and origin validation. Signature packets include hashed subpackets for timestamps, issuer keys, and preferences, with unhashed subpackets for revocations or notations, ensuring flexibility in certification. Early PGP versions used and RSA exclusively, but OpenPGP standardized support for multiple hash functions (e.g., , deprecated due to collision vulnerabilities identified in 2017) and algorithms like ElGamal, with modern implementations favoring variants for efficiency. For symmetrically encrypted messages lacking signatures, OpenPGP optionally employs a Modification Detection Code (MDC) packet—a hash of the decrypted and data—to guard against padding oracle attacks, though this offers without . Key management integrates with signatures through self-signatures on user IDs and subkeys, but message-level emphasizes direct signing to mitigate man-in-the-middle risks in untrusted channels. Vulnerabilities, such as weak hashes in legacy signatures, have prompted deprecation notices in RFC 4880 errata, urging migration to stronger primitives like SHA-256 with 2048-bit or larger keys.

Compatibility and Protocol Extensions

The OpenPGP protocol, formalized in RFC 4880 published in November 2007, establishes a standardized message format to promote interoperability across PGP implementations, including open-source variants like GnuPG and commercial products adhering to the specification. Core requirements mandate support for essential algorithms such as TripleDES (ID 2), CAST5 (ID 3), AES-128 (ID 7), DSA (ID 17), ElGamal (ID 20), and SHA-1 (ID 2), ensuring basic message exchange functions without proprietary dependencies. This framework obsoletes earlier standards like RFC 2440 (1998) and RFC 1991 (1996) while preserving essential structures for cross-system compatibility. Backward compatibility with legacy PGP versions, particularly 2.6.x from the early , is achieved through dual packet formats: old-format headers (one-octet length tags 0-15) for broad legacy support and new-format headers (with bit 6 set for partial body lengths and tags up to 63) for enhanced features. Implementations must accept version 3 (V3) keys and signatures—common in pre-OpenPGP PGP—though generation of V3 artifacts is deprecated in favor of version 4 (V4) for improved like longer key IDs and subkey separation. For instance, public-subkey packets (tag 14) are ignored by PGP 2.6.x without failure, and simple S2K derivation with and IDEA may be retained solely for decrypting old messages. Unrecognized elements, such as newer compression exceeding 13-bit ZIP limits in PGP 2.6.x, trigger graceful degradation rather than total rejection. Protocol extensions enable incremental evolution while minimizing disruption, primarily through IANA-registered for new algorithms and extensible subpacket structures. Symmetric-key algorithms expanded beyond PGP's original IDEA (ID 1) to include AES variants (IDs 7-10) in RFC 4880, with private ranges (100-110) reserved for experimental additions. Signature subpackets incorporate feature flags (type 30) to advertise capabilities like modified handling or new hashes, and critical bits (bit 7) enforce recognition of mandatory extensions. Private packet tags (60-63) allow vendor-specific or trial features without conflicting with standard parsers, which ignore unknown subpackets unless critical. A prominent example is RFC 6637 (June 2012), which integrates (ECC) via new public-key algorithm IDs—18 for ECDH and 19 for ECDSA—supporting NIST curves P-256, , and P-521 in uncompressed MPI format within existing key packets. This extension maintains compatibility by leveraging V4 key structures and avoiding alterations to core packet composition, with profiles defining minimal implementations (e.g., P-256 with AES-128 and SHA-256). Ongoing drafts propose further extensions, such as post-quantum algorithms with IDs 22-35 for lattice-based schemes, but these remain non-standardized as of 2025 and require explicit feature signaling for adoption. Such mechanisms ensure that extensions enhance functionality—e.g., stronger ciphers or quantum resistance—without invalidating prior compliant data.

Historical Development

Origins with Phil Zimmermann (1991–1993)

, a software engineer and privacy activist based in , initiated development of Pretty Good Privacy (PGP) in June 1991 as a tool to enable secure electronic mail in an era of growing digital surveillance threats. Motivated by proposed U.S. legislation such as Senate Bill 266, which sought to mandate mechanisms in devices to facilitate government access, Zimmermann aimed to distribute freely to counter potential erosion of individual privacy rights. He self-funded the project amid personal financial strain, reportedly missing five mortgage payments during the first half of 1991 while coding the software on systems. PGP version 1.0, the initial release, implemented a combining asymmetric public-key encryption for with symmetric encryption for bulk data, drawing on established algorithms like RSA and IDEA to provide , , and for messages. released PGP 1.0 as via the nascent in June 1991, positioning it as a instrument accessible to dissidents, journalists, and ordinary users facing insecure networks. This distribution method bypassed commercial channels and export controls on cryptographic software, allowing rapid proliferation despite U.S. regulations classifying such tools as munitions. From 1991 to 1993, Zimmermann iterated on PGP, releasing version 2.0 in 1992 with enhancements including support for multiple algorithms and improved key management, while maintaining its core emphasis on usability for non-experts. The software's "web of trust" model for key validation emerged during this period as an alternative to centralized certificate authorities, fostering decentralized verification among users. By 1993, PGP had garnered a dedicated following for its empirical resistance to interception, though its unpatented integration of licensed technologies like RSA drew early scrutiny from patent holders. In February 1993, the government initiated a into , the creator of Pretty Good Privacy (PGP), for allegedly violating the and associated (ITAR). These regulations classified cryptographic software employing strong algorithms like RSA as munitions, requiring an export license for dissemination outside the U.S.; PGP's public availability on the , which enabled international access without formal , prompted scrutiny by the U.S. Customs Service and Department of Justice. Zimmermann maintained that he developed PGP for domestic privacy needs amid concerns over surveillance, such as those during the , and did not intentionally it, attributing its global spread to third-party uploads. The probe focused on whether online posting constituted illegal , potentially carrying penalties of up to ten years imprisonment and $1 million in fines per violation. The investigation escalated throughout 1993, involving subpoenas to Zimmermann and associates, seizure of computers, and examination of PGP's for compliance. On October 12, 1993, Zimmermann testified before the House Foreign Affairs Subcommittee on Economic Policy, Trade, and the Environment, arguing that restrictions stifled U.S. innovation while failing to curb global proliferation, as the underlying mathematics were unpatentable and widely known. He highlighted that PGP's algorithms, including 1024-bit RSA keys, provided robust protection against unauthorized access, and controls treated tools as weapons equivalent to tanks. The three-year ordeal imposed severe financial strain, with Zimmermann accruing over $300,000 in legal fees, leading to filings by him and collaborators. By 1995, mounting legal challenges to ITAR's application to software, combined with PGP's publication in printed form via —circumventing digital export rules—weakened the government's position. On January 11, 1996, the Department of Justice announced the closure of the investigation without , stating no further action would be taken against or related parties. U.S. Attorney Henry Hubbard cited the probe's conclusion after reviewing evidence, though specifics on the decision—potentially influenced by policy shifts amid the chip's failure and industry lobbying—remained undisclosed. The outcome underscored tensions between imperatives and free speech in , paving the way for PGP's commercialization.

Commercialization via PGP Inc. (1996–1997)

Following the U.S. government's decision to drop its criminal investigation into PGP's without indictment in early 1996, founded PGP Inc. to formalize and expand the software's commercialization. The company incorporated to develop proprietary versions of PGP tailored for enterprise use, including enhanced support services and compliance with U.S. regulations, thereby enabling sales of full-strength cryptographic products to businesses while distinguishing these from distributions. In 1996, PGP Inc. merged with ViaCrypt, a prior licensee that had been producing commercial PGP implementations since the early 1990s, integrating ViaCrypt's established customer base and licensing infrastructure to accelerate . Under PGP Inc., development focused on version 5.0, which introduced improvements such as better integration with emerging standards drafts and support for multiple platforms, including Windows and , to appeal to corporate clients seeking reliable and file security tools. PGP 5.0 was released in mid-1997, with U.S. commercial and editions for following in , marking the company's first major proprietary release and emphasizing enhancements like simplified for non-technical users in organizational settings. This version facilitated revenue through licensed distributions, addressing prior limitations from patent disputes over algorithms like RSA by leveraging resolved licensing agreements. PGP Inc.'s brief independent operation culminated in its acquisition by Network Associates Inc. (NAI) in December 1997 for $36 million, just weeks after the PGP 5.0 rollout, shifting control to a larger firm capable of broader distribution and integration with enterprise antivirus products. This transaction provided and the team with resources for further innovation but also introduced corporate priorities that later influenced PGP's evolution.

Corporate Acquisitions and Asset Splits (1999–2002)

In late 1999 and early 2000, Network Associates underwent a major internal restructuring, dividing its operations into semi-autonomous units to streamline management and focus on core competencies; this included establishing PGP Security Inc. as a dedicated division responsible for the PGP encryption product line. The move aimed to preserve PGP's development amid broader company challenges, such as integrating prior acquisitions and addressing market pressures in antivirus and sectors. However, PGP Security faced resource constraints and shifting priorities under new leadership, leading to reduced investment in open-source code releases and feature expansions that had been hallmarks of earlier PGP iterations. Tensions escalated in 2001 when PGP creator Phil Zimmermann resigned from Network Associates on February 19, citing irreconcilable differences over the company's reluctance to publish full PGP source code and its pivot toward proprietary enhancements at the expense of community-driven improvements. Zimmermann, who had remained with the firm post-1997 acquisition, argued that withholding source code undermined PGP's foundational ethos of transparency and auditability, a stance rooted in the software's origins as freeware to counter export restrictions. In October 2001, Network Associates announced it would divest non-core assets, including the PGP desktop encryption and Gauntlet firewall product lines, as part of a broader strategy to refocus on antivirus offerings amid declining revenues and competitive erosion in enterprise security. By March 2002, Network Associates formally dissolved the PGP Security unit, offloading the Gauntlet firewall to third parties while selectively integrating select PGP technologies into its antivirus suite to bolster endpoint protection features. This partial asset split reflected the conglomerate's assessment that standalone PGP maintenance was unprofitable in a market favoring bundled solutions. In July 2002, Network Associates completed the sale of PGP's desktop and wireless encryption assets to a newly formed entity, PGP Corporation, backed by investors including Caufield & Byers; the transaction price was not publicly disclosed, though it enabled PGP Corporation to revive development under leaders like CEO Phil Dunkleberger and CTO Jon Callas, who prioritized enterprise-grade enhancements without the distractions of Network Associates' diversified portfolio. The divestiture marked a pivotal asset separation, restoring PGP to independent stewardship and averting potential stagnation under corporate consolidation.

Open Source Transition and OpenPGP Emergence (1997–2000s)

In June 1997, PGP Inc. released PGP version 5.0, which included a full rewrite of the codebase since the original 1991 version and introduced version 4 key formats that became foundational to subsequent standards. This release supported international cryptographic algorithms compliant with U.S. export regulations relaxed in prior years and anticipated the need for interoperability beyond proprietary implementations. Later that year, in July 1997, PGP Inc. proposed to the Internet Engineering Task Force (IETF) the creation of an open, non-proprietary standard called OpenPGP, granting the IETF permission to use the name for a protocol derived from PGP's message formats and operations. This initiative addressed growing demands for vendor-neutral specifications amid PGP's commercialization, enabling third-party developers to create compatible software without licensing proprietary code. The proposal led to the formation of the OpenPGP Working Group, which produced RFC 2440 ("OpenPGP Message Format") in November 1998, defining packet structures, algorithms (such as RSA, IDEA, and CAST-5), and procedures for encryption, signing, and key management. RFC 2440 emphasized backward compatibility with earlier PGP versions while promoting extensible, public-domain cryptographic primitives. The standardization effort coincided with the emergence of open-source implementations, as proprietary PGP restricted access for advocates. On December 20, 1997, Werner Koch released the initial version of (GnuPG), an open-source reimplementation compatible with PGP and the draft OpenPGP specifications, developed in response to calls for libre alternatives following Richard Stallman's advocacy. GnuPG, licensed under the GNU General Public License, quickly became a cornerstone for and in open-source ecosystems, with its 1.0 stable release in 1999 further solidifying adoption. By the early , OpenPGP's framework facilitated diverse tools like Bouncy Castle libraries and early mobile implementations, decoupling protocol evolution from PGP Inc.'s commercial trajectory after its 1997 acquisition by Network Associates, which focused on enterprise products. This transition enhanced scrutiny and innovation through public review, though it also introduced implementation variances addressed in later RFCs like 4880 (2007).

Standards and Implementations

Evolution of the OpenPGP Standard

The OpenPGP standard originated from efforts to standardize the proprietary PGP protocol for broader interoperability, with initial formalization occurring through (IETF) documents in the mid-1990s. RFC 1991, published in August 1996, defined basic PGP message exchange formats, including public-key encryption and digital signatures using algorithms like RSA and IDEA. This laid groundwork but remained tied to PGP-specific implementations. In November 1998, RFC 2440 introduced the OpenPGP message format, obsoleting RFC 1991 and establishing an open specification for packet-based structures supporting hybrid encryption, compression, and signing, independent of any single vendor. The standard emphasized modularity, allowing symmetric ciphers (e.g., CAST5), hash functions (e.g., ), and key types to be negotiated via packet tags. RFC 4880, released in November 2007, represented a significant revision of RFC 2440, introducing version 4 packet formats for keys and signatures to enhance flexibility and . Key changes included support for subkey binding with expiration dates, revocable user attributes, and improved handling of multiple hash algorithms, while deprecating weaker options like and addressing ambiguities in earlier parsing rules. This version became the de facto baseline for most implementations, enabling better resistance to certain attacks like chosen-text vulnerabilities through clarified padding requirements. Subsequent extensions via companion RFCs expanded capabilities: RFC 5581 (June 2009) added the symmetric , RFC 6637 (June 2012) integrated (ECC) for keys and signatures using curves like NIST P-256, and RFC 7435 (October 2014) incorporated and X25519 for post-quantum readiness precursors. The standard continued evolving under the IETF's OpenPGP Working Group to address cryptographic weaknesses and modern threats. Updates like RFC 9580, published in July 2024, obsolete RFC 4880 by mandating stronger defaults (e.g., deprecating RSA keys below 2048 bits, requiring or better hashes), introducing AEAD modes for , and supporting post-quantum algorithms via hybrid schemes. This refresh, developed over years of drafts, aimed to mitigate risks from outdated primitives exposed in empirical analyses, such as collisions, while maintaining through optional features. Implementations must now handle version 7 packets for these advancements, reflecting a shift toward proactive hardening amid advancing computational threats.

Major Open-Source Implementations

GnuPG, also known as , serves as the foremost open-source implementation of the OpenPGP standard outlined in RFC 4880, enabling encryption, digital signatures, and for secure data and communications. Initially developed by Werner Koch in 1997 amid U.S. export controls limiting proprietary PGP distribution, GnuPG provides a complete, libre alternative with support for symmetric and asymmetric cryptography, including RSA, DSA, and later elliptic curve variants, alongside features like smartcard integration via access modules for hardware tokens. Its , extensible architecture, and cross-platform compatibility—spanning , Windows, macOS, and embedded systems—have made it integral to tools like email clients (e.g., Thunderbird with Enigmail successor) and package managers, with ongoing releases addressing vulnerabilities and incorporating modern ciphers such as AES and . Sequoia-PGP represents a newer Rust-based implementation emphasizing memory safety, modular design, and enhanced security auditing through formal methods where feasible, comprising crates for low-level packet parsing and high-level operations. Developed as an alternative to GnuPG to mitigate historical implementation bugs, it prioritizes correctness in handling edge cases like malformed packets and supports OpenPGP features with a focus on deterministic builds to reduce supply-chain risks. Its adoption has grown in environments valuing Rust's type safety, such as secure messaging prototypes and key servers. For developer ecosystems, Bouncy Castle offers a low-level OpenPGP provider in and C#, facilitating integration into applications via the Java Cryptography Architecture (JCA) with APIs for , , and verification using algorithms like SHA and IDEA derivatives. Similarly, OpenPGP.js provides a compliant with RFC 9580 (superseding RFC 4880), enabling client-side in browsers and environments without native dependencies, though it trades some performance for portability across devices. These libraries extend OpenPGP utility beyond standalone tools, powering custom protocols in software like Android apps and web services.

Proprietary and Commercial Variants

Following the resolution of legal challenges in 1996, PGP Inc. was established by to develop and sell versions of PGP software, marking the shift toward commercial offerings with closed-source implementations. These included enhanced features for enterprise use, such as improved and integration capabilities, while maintaining compatibility with earlier versions. Network Associates acquired PGP Inc. in 1997 and continued development, releasing versions like PGP 6.x and 7.x, which supported both commercial licensing for businesses and limited distributions, but retained core engines. In 2002, after Network Associates discontinued PGP product lines, the intellectual property and development assets were transferred to the newly formed PGP Corporation, which resumed production. PGP Corporation released PGP 8.0 that year, available in both commercial and editions with for in the free version, followed by subsequent updates emphasizing enterprise-grade tools. Key products included PGP Desktop, a client application for emails, files, and whole disks, and PGP Universal Server, a gateway solution for automated policy-based , decryption, and key recovery in organizational environments. These variants offered vendor-supported updates, compliance certifications, and scalability features absent in purely open-source alternatives. PGP Corporation was acquired by Symantec on June 7, 2010, for approximately $300 million in cash, leading to the integration and rebranding of its proprietary PGP technologies into the Symantec Encryption portfolio. Products such as PGP Desktop became Symantec Encryption Desktop, providing endpoint encryption for data at rest and in transit, while server offerings evolved into Symantec Encryption Server for centralized management and whole-disk encryption capabilities like PGP Whole Disk Encryption. Symantec's versions prioritized enterprise interoperability, FIPS compliance, and professional support services, distinguishing them through licensed, closed-source enhancements over open-source OpenPGP implementations like GnuPG. Following Broadcom's 2019 acquisition of Symantec's enterprise security business, these products continued under PGP Encryption branding, with ongoing support for legacy deployments as of 2025.

Security Analysis

Historical Strengths and Empirical Validation

Pretty Good Privacy (PGP) demonstrated historical strengths through its pioneering hybrid model, which combined asymmetric for secure with efficient symmetric ciphers for data , enabling end-to-end protection without relying on trusted third parties. Introduced in 1991, PGP utilized the RSA algorithm for public-key operations and the (IDEA) for symmetric , both selected for their resistance to known attacks at the time; IDEA, in particular, was a novel designed to withstand differential and . This architecture compressed data prior to to minimize redundancy and enhance resistance to statistical attacks, while digital signatures ensured message integrity and authenticity via hash functions like initially, later upgraded to stronger options. The core of PGP have empirically validated their robustness over more than three decades, with no successful cryptanalytic breaks reported against properly implemented and keyed instances despite extensive scrutiny by academic and adversarial researchers. Early versions withstood challenges during the 1990s debates, where U.S. assessments implicitly acknowledged PGP's strength by classifying it as a munition rather than dismissing it as insecure. Subsequent migrations to AES for symmetric encryption and larger RSA or keys have preserved or enhanced this security margin, as AES-256 remains unbroken against brute-force or analytical attacks with current computing power. Real-world applications further substantiate PGP's empirical success, as encrypted communications protected by PGP resisted decryption by state actors in cases involving journalists, activists, and whistleblowers, with compromises attributable to errors or legal coercion rather than algorithmic failures. For example, PGP's deployment in privacy-sensitive contexts, such as secure file transfers and email among organizations, has maintained data without cryptographic breaches, underscoring the protocol's causal efficacy in causal-realist terms against . Audits and ongoing implementations in standards like OpenPGP confirm that, when configured with modern parameters (e.g., 4096-bit RSA or keys, SHA-256 hashing, AES-256), PGP achieves security levels equivalent to its component primitives.

Known Vulnerabilities and Implementation Flaws

In 2018, researchers disclosed EFAIL, a class of vulnerabilities affecting OpenPGP and S/MIME implementations in email clients, enabling attackers to exfiltrate plaintext from encrypted messages via active attacks that manipulate MIME structures or exploit cipher block chaining (CBC) mode padding oracles. These flaws arose from how clients like Thunderbird and Outlook processed encrypted content, such as rendering HTML or base64-decoding parts, allowing remote content to leak up to 35 bytes per request, potentially recovering full messages over multiple queries if the attacker controlled the network or email server. EFAIL impacted 10 of 35 tested OpenPGP clients and stemmed partly from the protocol's reliance on unauthenticated encryption modes without built-in protections against such exfiltration, though core cryptographic primitives remained intact. GnuPG, a primary OpenPGP implementation, has faced multiple code-level bugs, including CVE-2018-12020, where weak string-to-key (S2K) derivation functions allowed brute-force recovery of passphrases from memory dumps or side-channel leaks due to inefficient counting in iterated hashing. Another issue, CVE-2019-13050, enabled denial-of-service via "poisoned" public keys flooded with excessive signatures, bloating keyrings and slowing validation to the point of unusability, exploitable through keyserver imports dating back to design choices in signature handling. Subsequent fixes in GnuPG 2.2.23 addressed related DoS vectors in versions 2.2.21 and 2.2.22 (CVE-2020-25125), where malformed packets triggered infinite loops during decryption. Implementation flaws have also appeared in derived tools, such as OpenPGP.js, where CVE-2025-47934 permitted spoofing of signatures and encrypted emails by mishandling detached signature verification, allowing attackers to forge valid-appearing messages without key access. Historical parsers in GnuPG exhibited invalid reads (CVE-2015-1607), risking crashes or disclosures from malformed keyrings, underscoring persistent risks in boundary handling across versions. Despite patches, these incidents highlight how protocol flexibility—intended for interoperability—exposes surfaces to client-specific errors, with no fundamental breaks in algorithms like RSA or AES when used with strong parameters, but requiring vigilant updates to mitigate.

Usability Barriers and Human Factors

Despite its cryptographic robustness, Pretty Good Privacy (PGP) has faced persistent usability challenges stemming from its complex processes, which require users to generate asymmetric key pairs, securely exchange keys, verify key authenticity via fingerprints or the web-of-trust model, and revoke compromised keys—tasks that demand technical expertise often absent in non-specialist users. These barriers contribute to high error rates, as evidenced by a 1999 laboratory study of PGP 5.0 involving 22 novice participants, where none successfully met core security objectives such as encrypting messages to the correct recipient without inadvertently disclosing , even after explicit and repeated exposure. Human factors exacerbate these issues, including cognitive overload from opaque interfaces that fail to provide intuitive feedback on actions like distinguishing from signing or detecting key mismatches. In the same study, participants frequently misinterpreted PGP's "pen and paper" metaphors for signing, leading to skipped verifications and false senses of , with errors persisting across trials due to inadequate error recovery mechanisms. The web-of-trust model, intended to decentralize key validation, further confounds users by requiring subjective trust assessments across interconnected signatures, often resulting in unverified or malicious keys being accepted; empirical of keyserver from 2019 revealed that only a small fraction of PGP keys exhibit active usage patterns indicative of proper validation practices. Follow-up evaluations of modern PGP implementations, such as a study on Mailvelope, confirmed ongoing difficulties, with users struggling to integrate into workflows and verify key fingerprints accurately, achieving success rates below 50% for threat detection tasks like identifying substituted keys. Key fingerprint representation remains a bottleneck, as short identifiers (e.g., 32-bit key IDs) are prone to collisions exploitable in man-in-the-middle attacks, while full 160-bit fingerprints are cumbersome for manual comparison, leading to reliance on insecure shortcuts like visual similarity checks. These human-centric flaws, rooted in mismatched mental models between user expectations and PGP's decentralized design, have limited adoption to technically proficient communities, with surveys indicating that even experts overlook routine safeguards like key revocation in dynamic environments.

Exposure to Modern Threats Including Quantum Computing

OpenPGP implementations, including those based on PGP, rely on public-key algorithms such as RSA and variants for and digital signatures, which are vulnerable to attacks via . enables efficient of large integers and solving of problems, potentially allowing of encrypted sessions or forgery of signatures using sufficiently powerful quantum computers. In contrast, the symmetric components of OpenPGP, such as AES-256, face only a quadratic speedup threat from , rendering them quantum-resistant with appropriately sized keys. The "" strategy poses an immediate risk, where adversaries collect encrypted data today for future quantum decryption, underscoring the need for migration to post-quantum algorithms. As of 2025, no cryptographically relevant quantum computer exists, but projections indicate potential scalability within 10-20 years, prompting proactive efforts. The IETF has advanced drafts for integrating post-quantum public-key algorithms into OpenPGP, including lattice-based schemes like for encryption and or SPHINCS+ for signatures, to maintain compatibility while enhancing resistance. GnuPG, the primary open-source OpenPGP implementation, has explored support for these algorithms but faces challenges with overhead—post-quantum keys can exceed 3 KB, complicating and . ProtonMail has prototyped quantum-safe OpenPGP extensions using hybrid classical-post-quantum schemes to bridge the transition, emphasizing . However, widespread adoption lags due to the absence of finalized NIST-approved integrations in core OpenPGP tools, leaving legacy deployments exposed until full protocol updates occur. Beyond quantum threats, modern classical attacks exploit implementation weaknesses in OpenPGP, such as timing side-channels in or malleability in certain cipher modes, though these are mitigated in updated libraries like . Nation-state actors have demonstrated capabilities to brute-force weaker keys or exploit metadata leaks in PGP-encrypted communications, amplifying risks in high-stakes environments. Comprehensive audits recommend hybrid and key rotation to address these evolving vectors, prioritizing empirical validation over theoretical assurances.

Controversies and Criticisms

US Government Suppression and Export Control Battles

In 1991, developed and publicly released Pretty Good Privacy (PGP), an software utilizing strong , which quickly spread internationally via the without an export . The U.S. government classified strong cryptographic software as a munition under the and (ITAR), requiring prior approval for exports to prevent adversaries from accessing tools that could evade surveillance. This classification stemmed from national security concerns, viewing encryption as akin to weapons, though critics argued it hindered U.S. innovation and global privacy standards. By 1993, the U.S. Customs Service launched a three-year into , alleging violations of export controls due to PGP's unrestricted online availability, which enabled foreign downloads. The probe, involving the Departments of Justice and State, scrutinized whether PGP's dissemination constituted illegal export of controlled technology, potentially subjecting Zimmermann to fines or imprisonment; he faced financial strain from legal defense and withheld testimony under advice of counsel during congressional hearings. Concurrently, broader efforts included proposals like the for , reflecting government resistance to unescrowed strong encryption. The investigation concluded on January 11, 1996, when U.S. Attorney Michael J. Yamaguchi announced its closure without indictments, citing insufficient evidence and legal challenges asserting that cryptographic source code constituted protected speech under the First Amendment. Federal courts, in cases like Bernstein v. United States (1996), reinforced this by striking down prior restraints on encryption exports as unconstitutional. Export controls eased thereafter; President Clinton's 1996 executive order liberalized rules for commercial encryption up to 56-bit keys, with full deregulation for open-source and most commercial software by 2000, allowing PGP's unrestricted global distribution except to embargoed nations. These battles highlighted tensions between security imperatives and free expression, ultimately favoring broader access to privacy tools despite initial suppression attempts.

Design Flaws and Overstated Privacy Claims

OpenPGP, the standard underlying PGP implementations, does not encrypt subject lines or certain headers, exposing this metadata to email providers, network observers, and potential adversaries during transit. This design choice stems from compatibility with existing protocols, which separate headers from body content, but it undermines by revealing communication topics and patterns without additional measures like header extensions. The web-of-trust model for public key validation relies on decentralized signatures to establish authenticity, yet empirical analysis shows it suffers from sparse connectivity, with most users unable to form reliable trust paths due to limited key signing events and keyserver issues. Keyservers, intended to distribute and trust , have faced scalability problems, spam, and desynchronization, rendering the system ineffective for widespread verification as of 2019. OpenPGP lacks native support for , meaning that compromise of a long-term private key retroactively exposes all prior encrypted messages encrypted under the corresponding public key, a vulnerability absent in protocols like Signal that rotate ephemeral keys per session. The message format's complexity, including nested packet structures and optional compression, has facilitated attacks such as EFAIL (disclosed in May 2018), where adversaries manipulate encrypted content in transit to exfiltrate via client-side rendering flaws. Advocates have portrayed PGP as offering robust end-to-end for , yet this overlooks inherent metadata leakage and the protocol's dependence on flawless user , which studies show fails in practice for non-experts. Claims of "unbreakable" , rooted in the strength of algorithms like RSA and AES, ignore design-level exposures to and the absence of protections against quantum threats in default configurations, as no hybrid post-quantum modes were standardized until recent drafts. These limitations have led cryptographers to argue that modern systems would avoid PGP's archaic structure, prioritizing simplicity and metadata resistance over .

Key Management Risks and Identity Binding Issues

In PGP, private keys are safeguarded primarily by user-chosen passphrases, rendering them susceptible to compromise through weak passphrase selection, brute-force attacks, or theft via malware if stored on compromised devices. The long-lived nature of PGP root keys, often retained indefinitely and tied to a user's identity, amplifies this risk by extending the window for exposure without routine rotation, as regenerating and redistributing keys disrupts established trust networks. A notable incident occurred on December 31, 2022, when Bitcoin Core developer Luke Dashjr reported the compromise of his PGP private key—likely via a hacked server—enabling attackers to drain over 200 BTC (valued at approximately $3.3 million) from his wallet through unauthorized transactions. Key revocation poses additional challenges, as it requires access to the private key to generate a valid revocation certificate, which may be impossible if the key is lost or already compromised; even when feasible, propagation across decentralized keyservers is inconsistent, and users rarely check for revocations in practice. This is compounded by PGP's encouragement of static keys, where rotation is discouraged due to the effort of re-signing and re-verifying signatures in social graphs, leaving compromised keys active longer than necessary. Empirical usability studies highlight that tasks like revocation are error-prone for non-experts, often overlooked amid the system's complexity. Identity binding in PGP relies on the Web of Trust model, where users sign public keys to vouch for their association with claimed identities, but this decentralized approach falters due to insufficient verification: keyservers allow unverified uploads with arbitrary email claims, enabling impersonation without robust checks. Trust propagation through signature chains is unreliable, as most users accept short or unexamined paths, while experts distrust the system entirely, favoring direct key exchanges over the infrastructure. Consequently, the model permits sybil-like attacks or forged bindings, undermining PGP's ability to causally link keys to real-world identities in adversarial settings, with consensus among cryptographers that the Web of Trust has proven fundamentally broken for scalable, secure authentication.

Impact and Current Status

Influence on Cryptographic Practices and Privacy Advocacy

PGP's release in 1991 by popularized the application of to , combining symmetric algorithms like IDEA or with asymmetric ones such as RSA for efficient, secure , thereby influencing subsequent hybrid cryptosystems in messaging protocols. This approach demonstrated the feasibility of for non-experts, prompting the development of interoperable standards; PGP formed the basis for the OpenPGP specification, formalized in RFC 4880 by the in 2007, which defines packet formats, , and mechanisms for broad compatibility. Implementations adhering to OpenPGP, including GnuPG released in 1999, extended PGP's model by supporting modern algorithms like AES while maintaining backward compatibility, embedding these practices into tools for secure file handling and software distribution. PGP introduced the "" model, a decentralized alternative to centralized certificate authorities, where users mutually certify keys through signatures, fostering validation without reliance on hierarchical intermediaries. This influenced cryptographic practices by emphasizing user in identity verification, contrasting with X.509-based systems, and inspired key-signing events and keyserver networks that persist in contemporary OpenPGP ecosystems, though it highlighted challenges in scalability and revocation. In privacy advocacy, PGP galvanized opposition to U.S. export restrictions on during the "," as Zimmermann's distribution of the software via the evaded munitions controls under the , leading to a federal investigation from 1993 to 1996 that underscored civilian rights to tools. The case amplified calls for policy reform, contributing to the 1999 relaxation of export rules and bolstering arguments for unrestricted access to as a bulwark against surveillance, with articulating that "... is the best route to " in communications. This advocacy legacy endures in open-source successors like GnuPG, which prioritize accessibility and auditability, influencing broader movements for amid ongoing debates over government backdoors.

Barriers to Widespread Adoption

Despite its technical robustness, PGP's decentralized web of trust model has proven insufficient for scalable identity verification, as users rarely participate in key-signing events or maintain comprehensive trust networks, leading to frequent reliance on unverified keys or key servers prone to compromise. This contrasts with centralized systems like TLS, where certificate authorities provide automated validation, reducing the cognitive burden and enabling broader deployment. Studies on tools confirm that identity assurance remains a core obstacle, with PGP's approach exacerbating adoption hurdles in diverse user populations. Major email providers, such as and , have resisted integrating PGP due to its incompatibility with content-scanning features essential for spam detection, , and filtering; for instance, Gmail's architecture prioritizes server-side analysis, rendering client-side PGP disruptive to these operations. This institutional inertia creates a coordination barrier, as widespread adoption requires symmetric support from both senders and recipients, yet penetration remains low—estimated at under 1% of traffic in surveys of technical communities. Misaligned incentives further compound this, with providers favoring proprietary or hybrid schemes that retain data access for compliance and monetization. Technical limitations, including the absence of in core PGP implementations, expose past communications to key compromise risks, deterring users in high-stakes environments where ephemeral keys are standard, as in protocols like Signal. Additionally, PGP's origins as a file-encryption tool limit its seamlessness in real-time messaging, where metadata leakage and lack of deniability persist, prompting shifts toward purpose-built alternatives. Regulatory environments in surveillance-heavy jurisdictions impose further friction, with policies discouraging end-to-end tools that evade lawful access, as evidenced by ongoing debates over encryption backdoors. These factors collectively sustain PGP's niche status, with adoption confined primarily to privacy advocates and activists rather than mainstream consumers or enterprises.

Relevance and Alternatives in 2025

In 2025, Pretty Good Privacy (PGP) and its implementation OpenPGP retain relevance primarily in specialized domains such as secure for journalists, activists, and technical professionals requiring verifiable signatures and flexible without dependence on proprietary platforms. The protocol's , combining symmetric efficiency with asymmetric security, remains resistant to brute-force attacks when using contemporary parameters like AES-256 for bulk data and for . However, its adoption remains limited to a small, technically proficient user base, as evidenced by persistent keyserver queries and integration in tools like GnuPG, rather than mass deployment. PGP's declining prominence stems from inherent complexities in , distribution, and revocation, which deter non-experts amid rising threats like metadata leakage and implementation vulnerabilities. Integrated (E2EE) in consumer tools has supplanted PGP for routine , rendering it "good enough" for most against non-state adversaries but insufficient for seamless usability. Prominent alternatives include managed E2EE email providers like ProtonMail, which internally leverages PGP-inspired mechanisms with zero-access and automatic key handling, processing millions of daily messages while ensuring server-side privacy. Tuta Mail employs AES-256 and RSA hybrids to subjects and metadata, bypassing PGP's manual workflows for broader accessibility. For file and , tools like offer disk-level protection with pluggable algorithms, while developer libraries such as libsodium provide misuse-resistant primitives for custom implementations, emphasizing simplicity over PGP's expansive feature set. Messaging protocols like Signal's, with built-in via the , address PGP's lacks in ephemeral keys and deniability for real-time exchanges.

References

  1. https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html
  2. https://www.openpgp.org/about/history/
  3. https://www.computerworld.com/article/1331259/from-arms-violations-to-gathering-dust-the-strange-history-of-pgp.html
  4. https://www.openpgp.org/about/standard/
  5. https://datatracker.ietf.org/doc/html/rfc4880
  6. http://www.cypherspace.org/adam/timeline/
  7. https://www.rfc-editor.org/rfc/rfc9580.html
  8. https://sequoia-pgp.gitlab.io/sequoia-wot/
  9. https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust
  10. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2
  11. https://www.linuxjournal.com/content/pretty-good-privacy-pgp-and-digital-signatures
  12. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.1
  13. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3
  14. https://datatracker.ietf.org/doc/html/rfc4880#section-5.13
  15. https://datatracker.ietf.org/doc/html/rfc4880#section-9
  16. https://datatracker.ietf.org/doc/html/rfc4880#section-9.4
  17. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.4
  18. https://datatracker.ietf.org/doc/html/rfc4880#section-12.1
  19. https://datatracker.ietf.org/doc/html/rfc4880#section-4.2
  20. https://datatracker.ietf.org/doc/html/rfc4880#section-5.5.2
  21. https://datatracker.ietf.org/doc/html/rfc4880#section-3.7.2.2
  22. https://datatracker.ietf.org/doc/html/rfc4880#section-5.6
  23. https://datatracker.ietf.org/doc/html/rfc4880#section-10
  24. https://www.rfc-editor.org/rfc/rfc4880.html#section-9
  25. https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.1
  26. https://datatracker.ietf.org/doc/html/rfc4880#section-4.3
  27. https://www.rfc-editor.org/rfc/rfc6637.html#section-5
  28. https://www.rfc-editor.org/rfc/rfc6637.html#section-12
  29. https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/
  30. https://hiddenheroes.netguru.com/philip-zimmermann
  31. https://philzimmermann.com/
  32. https://www.jscape.com/blog/pgp-vs-gpg-the-key-differences-explained
  33. https://www.nytimes.com/1996/01/12/business/data-secrecy-export-case-dropped-by-us.html
  34. http://dubois.com/pgp-case/
  35. https://philzimmermann.com/EN/news/PRZ_case_dropped.html
  36. https://readingroom.law.gsu.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=2264&context=gsulr
  37. https://irp.fas.org/congress/1993_hr/931012_zimmerman.htm
  38. https://philzimmermann.com/EN/testimony/index.html
  39. https://www.isoc.org/inet97/proceedings/A4/A4_1.HTM
  40. https://old.lysator.liu.se/~kjell-e/tekla/linux/security/bugtraq/2000/pgp-2000-06.html
  41. https://www.wired.com/1997/06/breaking-the-crypto-barrier/
  42. https://www.internethalloffame.org/official-biography-philip-zimmermann/
  43. https://betanews.com/2000/01/14/network-associates-break-up/
  44. https://philzimmermann.com/EN/news/PRZ_leaves_NAI.html
  45. https://www.cnet.com/tech/tech-industry/zimmermann-leaves-network-associates/
  46. https://www.theregister.com/2001/10/12/network_associates_puts_pgp_up/
  47. https://www.crn.com/news/security/18828125/network-associates-to-buy-out-remaining-mcafee-com-shares
  48. https://www.crn.com/news/security/18838233/network-associates-sells-pgp-products-to-new-company
  49. https://www.buyoutsinsider.com/pgp-encrypts-14-million-deal/
  50. https://adtmag.com/articles/2002/08/26/pretty-good-news-from-pgp.aspx
  51. https://openpgp.dev/book/openpgp.html
  52. https://www.gnupg.org/
  53. https://www.rfc-editor.org/rfc/rfc4880.html
  54. https://www.rfc-editor.org/rfc/rfc6637.html
  55. https://datatracker.ietf.org/doc/rfc9580/history/
  56. https://theconversation.com/a-brief-history-of-gnupg-vital-to-online-security-but-free-and-underfunded-80800
  57. https://wiki.gnupg.org/OtherFreeSoftwareOpenPGP
  58. https://sequoia-pgp.org/
  59. https://www.openpgp.org/software/developer/
  60. https://openpgpjs.org/
  61. https://github.com/openpgpjs/openpgpjs
  62. https://pgpi.didisoft.com/news/
  63. https://www.securityweek.com/symantec-completes-acquisition-pgp-and-guardianedge/
  64. https://www.forbes.com/sites/firewall/2010/04/29/symantec-acquires-encryption-provider-pgp-for-300-million/
  65. https://knowledge.broadcom.com/external/article/150915/pgp-encryption-server-benefits-and-consi.html
  66. https://users.ece.cmu.edu/~adrian/630-f04/PGP-intro.html
  67. https://www.upguard.com/blog/what-is-pgp-encryption
  68. https://securityscorecard.com/blog/how-does-pgp-encryption-work-and-is-it-still-secure-in-2025/
  69. https://exceptionfactory.com/posts/2021/08/16/surveying-pretty-good-privacy-after-three-decades/
  70. https://www.usenix.org/conference/usenixsecurity18/presentation/poddebniak
  71. https://efail.de/
  72. https://lists.gnu.org/archive/html/info-gnu/2018-06/msg00005.html
  73. https://www.gnupg.org/news.html
  74. https://codeanlabs.com/blog/research/cve-2025-47934-spoofing-openpgp-js-signatures/
  75. https://github.com/hannob/pgpbugs
  76. https://www.gnupg.org/download/release_notes.html
  77. https://secushare.org/PGP
  78. https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Encrypt/USENIX.pdf
  79. https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
  80. https://journals.umcs.pl/ms/article/view/6947
  81. https://ar5iv.labs.arxiv.org/html/1510.08555
  82. https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_dechand.pdf
  83. https://www.researchgate.net/publication/334200564_Encryption_for_the_masses_An_analysis_of_PGP_key_usage
  84. https://www.ietf.org/archive/id/draft-wussler-openpgp-pqc-01.html
  85. https://proton.me/blog/post-quantum-encryption
  86. https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/08/
  87. https://lists.gnupg.org/pipermail/gnupg-users/2025-January/067463.html
  88. https://www.gnupg.org/documentation/manuals/gnupg-devel/Compliance-Options.html
  89. https://www.sciencedirect.com/science/article/pii/S0167404824001846
  90. https://dl.acm.org/doi/fullHtml/10.1145/3600160.3605049
  91. https://www.brookings.edu/articles/a-brief-history-of-u-s-encryption-policy/
  92. https://proton.me/support/does-protonmail-encrypt-email-subjects
  93. https://www.expressvpn.com/blog/pretty-good-privacy/
  94. https://blog.mailfence.com/openpgp-public-key/
  95. https://inversegravity.net/2019/web-of-trust-dead/
  96. https://security.stackexchange.com/questions/68583/is-the-pgp-web-of-trust-keyserver-infrastructure-permanently-broken
  97. https://www.privacyguides.org/en/email/
  98. https://www.bbc.com/news/technology-44107570
  99. https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/
  100. https://www.cryptomathic.com/blog/cryptographic-key-management-the-risks-and-mitigations
  101. https://www.reddit.com/r/privacy/comments/4cbmwx/how_safe_is_gpg_password_protection_for_private/
  102. https://www.theblock.co/post/198688/bitcoin-developer-pgp-exploit
  103. https://crypto.stackexchange.com/questions/25297/how-do-revocation-certificates-work-in-pgp
  104. https://www.ietf.org/archive/id/draft-dkg-openpgp-revocation-00.html
  105. https://www.openpgp.org/about/
  106. https://darknetdiaries.com/transcript/12/
  107. https://www.ieee-security.org/TC/SP2017/papers/84.pdf
  108. https://news.ycombinator.com/item?id=6662798
  109. https://jbonneau.com/doc/ASBDNS17-IEEESP-secure_messaging_obstacles.pdf
  110. https://ijcaonline.org/archives/volume186/number56/ansong-2024-ijca-924283.pdf
  111. https://petsymposium.org/popets/2021/popets-2021-0037.pdf
  112. https://www.openpgp.org/
  113. https://thecybersecguru.com/tutorials/complete-pgp-encryption-guide/
  114. https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/
  115. https://www.linkedin.com/posts/sohmc_pgp-gpg-gnupg-activity-7372331051840479232-h_nU
  116. https://blog.mailfence.com/best-secure-email-providers/
  117. https://cyberinsider.com/email/best-encrypted-email/
  118. https://www.privacyguides.org/en/encryption/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.