Editing Pretty Good Privacy (section)

==Design==
[[File:PGP diagram.svg|thumb|500px|How PGP encryption works visually]]

PGP&nbsp;encryption uses a serial combination of [[cryptographic hash function|hashing]], [[data compression]], [[symmetric-key cryptography]], and finally [[public-key cryptography]]; each step uses one of several supported [[algorithm]]s. 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===
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.<ref>{{cite web|last=Furley|first=Paul M|title=PGP public key example|url=https://www.paulfurley.com/pgp-public-key-example/|url-status=dead|archive-url=https://web.archive.org/web/20181221182643/https://www.paulfurley.com/pgp-public-key-example/|archive-date=21 December 2018|at=There are shorter ways of referring to PGP keys|quote=can print it on my business card instead of trying to print my whole public key}}</ref><ref>{{Cite tweet|number=557692432494915584|user=marciahofmann|title=my new business card (with image)|author=Marcia Hofmann|date=20 January 2015|author-link=Marcia Hofmann|access-date=30 July 2020|location=}}</ref>

===Compatibility===
As PGP evolves, versions that support newer features and [[algorithm]]s 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.<ref>{{Cite web|title=PGP User's Guide, Volume II: Special Topics|url=https://web.pa.msu.edu/reference/pgpdoc2.html|access-date=2020-11-01|website=web.pa.msu.edu|archive-date=November 6, 2020|archive-url=https://web.archive.org/web/20201106035213/https://web.pa.msu.edu/reference/pgpdoc2.html|url-status=live}}</ref>

===Confidentiality===
PGP can be used to send messages confidentially.<ref>{{Cite IETF|rfc=1991|last3=Zimmermann|first3=P.|last1=Atkins|first1=D.|last2=Stallings|first2=W.|date=August 1996|title=PGP Message Exchange Formats}}</ref> For this, PGP uses a [[hybrid cryptosystem]] by combining [[Symmetric key encryption|symmetric-key encryption]] and public-key encryption. The message is encrypted using a symmetric encryption algorithm, which requires a [[Symmetric-key algorithm|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 one of several supported public-key algorithms. To do so, PGP computes a [[cryptographic hash function|hash]], or digest, from the plaintext and then creates the digital signature from that hash using the sender's private key.

===Web of trust===
{{Main|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 '[[Public key certificate|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:

{{quotation|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===
{{Main|Public key certificate}}
In the (more recent) OpenPGP specification, ''trust signatures'' can be used to support creation of [[certificate authority|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 ('[[certificate revocation|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 list]]s 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===
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."<ref>{{cite book| last =Schneier| first =Bruce| author-link =Bruce Schneier| title =Applied Cryptography| publisher =[[John Wiley & Sons|Wiley]]| date =October 9, 1995| location =[[New York City|New York]]| page =587| isbn= 0-471-11709-9}}</ref> Early versions of PGP have been found to have theoretical vulnerabilities and so current versions are recommended.<ref>{{Cite magazine|last=Messmer|first=Ellen|date=August 28, 2000|title=Security flaw found in Network Associates' PGP|url=https://books.google.com/books?id=JxkEAAAAMBAJ&pg=PA81|magazine=[[Network World]]|location=Southbourough, Massachusetts|publisher=IDG|volume=17|issue=35|page=81|via=Google Books|access-date=May 2, 2017|archive-date=October 5, 2024|archive-url=https://web.archive.org/web/20241005182347/https://books.google.com/books?id=JxkEAAAAMBAJ&pg=PA81#v=onepage&q&f=false|url-status=live}}</ref> 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)|RSA]] algorithm was used to encrypt session keys. RSA's security depends upon the [[one-way function]] nature of mathematical [[integer factorization|integer factoring]].<ref>{{cite book |last=Nichols |first=Randall |title=ICSA Guide to Cryptography |publisher=[[McGraw-Hill|McGraw Hill]] |year=1999 |page=267 |isbn= 0-07-913759-8}}</ref> Similarly, the symmetric key algorithm used in PGP version 2 was [[International Data Encryption Algorithm|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 (computing)|trojan horse]] or [[keystroke logging]] software/hardware on the target computer to capture encrypted [[Keyring (cryptography)|keyrings]] and their passwords). The [[FBI]] has already used this attack against PGP<ref>{{cite web |url=https://www.epic.org/crypto/scarfo.html |title=United States v. Scarfo (Key-Logger Case) |publisher=Epic.org |access-date=2010-02-08 |archive-date=October 8, 2021 |archive-url=https://web.archive.org/web/20211008114412/https://www.epic.org/crypto/scarfo.html |url-status=live }}</ref><ref>{{cite web|last=McCullagh |first=Declan |url=https://www.cnet.com/news/feds-use-keylogger-to-thwart-pgp-hushmail/ |archive-url=https://web.archive.org/web/20170324015726/https://www.cnet.com/news/feds-use-keylogger-to-thwart-pgp-hushmail/ |url-status=dead |archive-date=March 24, 2017 |title=Feds use keylogger to thwart PGP, Hushmail &#124; Tech news blog – CNET News.com |publisher=News.com |date=July 10, 2007 |access-date=2010-02-08}}</ref> 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 (computers)|Psion]] [[Personal digital assistant|PDA]]s belonging to members of the [[Red Brigades|Red Brigade]] indicated that neither the [[Italian police]] nor the FBI were able to decrypt PGP-encrypted files stored on them.<ref>{{cite web|last1=Grigg|first1=Ian|title=PGP Encryption Proves Powerful|url=https://www.metzdowd.com/pipermail/cryptography/2003-May/004808.html|date=2003|access-date=February 15, 2022|archive-date=October 5, 2024|archive-url=https://web.archive.org/web/20241005182349/https://www.metzdowd.com/pipermail/cryptography/2003-May/004808.html|url-status=live}}</ref>{{Unreliable source?|date=June 2018}}

A second incident in December 2006, (see ''[[In re Boucher]]''), involving [[United States Customs Service|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 to the United States Constitution|Fifth Amendment]] rights i.e. a suspect's constitutional right not to incriminate himself.<ref>{{cite web |last=McCullagh |first=Declan |url=https://www.news.com/8301-13578_3-9834495-38.html?tag=nefd.blgs |title=Judge: Man can't be forced to divulge encryption passphrase &#124; The Iconoclast - politics, law, and technology - CNET News.com |publisher=News.com |date=December 14, 2007 |access-date=2010-02-08 |archive-date=October 5, 2024 |archive-url=https://web.archive.org/web/20241005182348/https://www.cnet.com/?tag=nefd.blgs |url-status=live }}</ref><ref>{{cite web |last=McCullagh |first=Declan |url=https://www.news.com/8301-13578_3-9854034-38.html |title=Feds appeal loss in PGP compelled-passphrase case &#124; The Iconoclast - politics, law, and technology - CNET News.com |publisher=News.com |date=January 18, 2008 |access-date=2010-02-08 |archive-date=October 10, 2008 |archive-url=https://web.archive.org/web/20081010232248/http://www.news.com/8301-13578_3-9854034-38.html |url-status=live }}</ref> 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.<ref>{{cite web|url=https://www.cnet.com/news/judge-orders-defendant-to-decrypt-pgp-protected-laptop/|title=Judge orders defendant to decrypt PGP-protected laptop|last=McCullagh|first=Declan|date=February 26, 2009|publisher=CNET news|access-date=2009-04-22|archive-date=January 9, 2022|archive-url=https://web.archive.org/web/20220109033718/https://www.cnet.com/news/judge-orders-defendant-to-decrypt-pgp-protected-laptop/|url-status=live}}</ref>

Evidence suggests that {{asof|2007|lc=yes}}, [[British police]] investigators are unable to break PGP,<ref>{{Cite news |url=https://www.theregister.co.uk/2007/11/14/ripa_encryption_key_notice |title=Animal rights activist hit with RIPA key decrypt demand |work=The Register |author=John Leyden |date=November 14, 2007 |access-date=August 10, 2017 |archive-date=August 10, 2017 |archive-url=https://web.archive.org/web/20170810133521/https://www.theregister.co.uk/2007/11/14/ripa_encryption_key_notice |url-status=live }}</ref> so instead have resorted to using [[Regulation of Investigatory Powers Act 2000|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.<ref>{{Cite news |url=https://www.theregister.co.uk/2009/11/24/ripa_jfl/page2.html |title=UK jails schizophrenic for refusal to decrypt files |work=The Register |author=Chris Williams |date=November 24, 2009 |page=2 |access-date=August 10, 2017 |archive-date=October 5, 2024 |archive-url=https://web.archive.org/web/20241005182453/https://www.theregister.com/2009/11/24/ripa_jfl?page=2 |url-status=live }}</ref>

PGP as a [[cryptosystem]] has been criticized for complexity of the standard, implementation and very low usability of the user interface<ref>{{Cite web|url=https://arstechnica.com/information-technology/2016/12/op-ed-im-giving-up-on-pgp/|title=Op-ed: I'm throwing in the towel on PGP, and I work in security|last=Staff|first=Ars|date=2016-12-10|website=Ars Technica|language=en-us|access-date=2019-07-17|archive-date=July 17, 2019|archive-url=https://web.archive.org/web/20190717111526/https://arstechnica.com/information-technology/2016/12/op-ed-im-giving-up-on-pgp/|url-status=live}}</ref> including by recognized figures in cryptography research.<ref>{{Cite web|url=https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/|title=What's the matter with PGP?|date=2014-08-13|website=A Few Thoughts on Cryptographic Engineering|language=en|access-date=2019-07-17|archive-date=October 5, 2024|archive-url=https://web.archive.org/web/20241005182349/https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/|url-status=live}}</ref><ref name="2015_marlinspike" /> 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, [[Cipher feedback|CFB]] mode, S2K password hashing).<ref>{{Cite web|url=https://latacora.micro.blog/2019/07/16/the-pgp-problem.html|title=Latacora - The PGP Problem|website=latacora.micro.blog|date=July 16, 2019|access-date=2019-07-17|archive-date=October 5, 2024|archive-url=https://web.archive.org/web/20241005182455/https://www.latacora.com/blog/2019/07/16/the-pgp-problem/|url-status=live}}</ref> 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.<ref>{{Cite web|url=https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf|title=Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels|access-date=July 17, 2019|archive-date=June 26, 2019|archive-url=https://web.archive.org/web/20190626111129/https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf|url-status=live}}</ref>