Editing Public-key cryptography (section)

== Weaknesses ==
As with all security-related systems, there are various potential weaknesses in public-key cryptography.  Aside from poor choice of an asymmetric key algorithm (there are few that are widely regarded as satisfactory) or too short a key length, the chief security risk is that the private key of a pair becomes known.  All security of messages, authentication, etc., will then be lost.

Additionally, with the advent of [[quantum computing]], many asymmetric key algorithms are considered vulnerable to attacks, and new quantum-resistant schemes are being developed to overcome the problem.<ref>{{Cite journal |last1=Escribano Pablos |first1=José Ignacio |last2=González Vasco |first2=María Isabel |date=April 2023 |title=Secure post-quantum group key exchange: Implementing a solution based on Kyber |url=https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/cmu2.12561 |journal=IET Communications |language=en |volume=17 |issue=6 |pages=758–773 |doi=10.1049/cmu2.12561 |hdl=10016/37141 |s2cid=255650398 |issn=1751-8628|hdl-access=free }}</ref><ref>{{Citation |last1=Stohrer |first1=Christian |title=Asymmetric Encryption |date=2023 |work=Trends in Data Protection and Encryption Technologies |pages=11–14 |editor-last=Mulder |editor-first=Valentin |place=Cham |publisher=Springer Nature Switzerland |language=en |doi=10.1007/978-3-031-33386-6_3 |isbn=978-3-031-33386-6 |last2=Lugrin |first2=Thomas |editor2-last=Mermoud |editor2-first=Alain |editor3-last=Lenders |editor3-first=Vincent |editor4-last=Tellenbach |editor4-first=Bernhard|doi-access=free }}</ref>

=== Algorithms ===
All public key schemes are in theory susceptible to a "[[brute-force attack|brute-force key search attack]]".<ref>{{cite book|last1=Paar|first1=Christof|first2=Jan|last2=Pelzl|first3=Bart|last3=Preneel|url=http://www.crypto-textbook.com|title=Understanding Cryptography: A Textbook for Students and Practitioners|publisher=Springer|year=2010|isbn=978-3-642-04100-6}}</ref> However, such an attack is impractical if the amount of computation needed to succeed – termed the "work factor" by [[Claude Shannon]] – is out of reach of all potential attackers. In many cases, the work factor can be increased by simply choosing a longer key. But other algorithms may inherently have much lower work factors, making resistance to a brute-force attack (e.g., from longer keys) irrelevant. Some special and specific algorithms have been developed to aid in attacking some public key encryption algorithms; both [[RSA (algorithm)|RSA]] and [[ElGamal encryption]] have known attacks that are much faster than the brute-force approach.{{cn|date=June 2024}} None of these are sufficiently improved to be actually practical, however.

Major weaknesses have been found for several formerly promising asymmetric key algorithms. The [[Merkle–Hellman knapsack cryptosystem|"knapsack packing" algorithm]] was found to be insecure after the development of a new attack.<ref>{{Cite journal|last1=Shamir|first1=Adi|date=November 1982|title=A polynomial time algorithm for breaking the basic Merkle-Hellman cryptosystem|url=https://ieeexplore.ieee.org/document/4568386|journal=23rd Annual Symposium on Foundations of Computer Science (SFCS 1982)|pages=145–152|doi=10.1109/SFCS.1982.5}}</ref> As with all cryptographic functions, public-key implementations may be vulnerable to [[side-channel attack]]s that exploit information leakage to simplify the search for a secret key. These are often independent of the algorithm being used. Research is underway to both discover, and to protect against, new attacks.

=== Alteration of public keys ===
Another potential security vulnerability in using asymmetric keys is the possibility of a [[Man-in-the-middle attack|"man-in-the-middle" attack]], in which the communication of public keys is intercepted by a third party (the "man in the middle") and then modified to provide different public keys instead. Encrypted messages and responses must, in all instances, be intercepted, decrypted, and re-encrypted by the attacker using the correct public keys for the different communication segments so as to avoid suspicion.{{citation needed| reason=deleted blog references|date=January 2024}}

A communication is said to be insecure where data is transmitted in a manner that allows for interception (also called "[[Sniffing attack|sniffing]]"). These terms refer to reading the sender's private data in its entirety. A communication is particularly unsafe when interceptions can not be prevented or monitored by the sender.<ref>
{{cite web
 |url=https://www.upguard.com/blog/man-in-the-middle-attack#mitm-sniffing
 |title=What Is a Man-in-the-Middle Attack and How Can It Be Prevented – What is the difference between a man-in-the-middle attack and sniffing?
 |last=Tunggal |first=Abi
 |date=February 20, 2020
 |website=UpGuard
 |access-date=June 26, 2020
}}{{sps|date=January 2024}}</ref>

A man-in-the-middle attack can be difficult to implement due to the complexities of modern security protocols. However, the task becomes simpler when a sender is using insecure media such as public networks, the [[Internet]], or wireless communication. In these cases an attacker can compromise the communications infrastructure rather than the data itself. A hypothetical malicious staff member at an [[Internet service provider]] (ISP) might find a man-in-the-middle attack relatively straightforward. Capturing the public key would only require searching for the key as it gets sent through the ISP's communications hardware;  in properly implemented asymmetric key schemes, this is not a significant risk.{{citation needed| reason=deleted blog references|date=January 2024}}

In some advanced man-in-the-middle attacks, one side of the communication will see the original data while the other will receive a malicious variant. Asymmetric man-in-the-middle attacks can prevent users from realizing their connection is compromised. This remains so even when one user's data is known to be compromised because the data appears fine to the other user. This can lead to confusing disagreements between users such as "it must be on your end!" when neither user is at fault. Hence, man-in-the-middle attacks are only fully preventable when the communications infrastructure is physically controlled by one or both parties; such as via a wired route inside the sender's own building. In summation, public keys are easier to alter when the communications hardware used by a sender is controlled by an attacker.<ref>
{{cite web
 |url=https://www.upguard.com/blog/man-in-the-middle-attack#where |title=What Is a Man-in-the-Middle Attack and How Can It Be Prevented - Where do man-in-the-middle attacks happen?
 |last=Tunggal
 |first=Abi
 |date=February 20, 2020
 |website=UpGuard
 |access-date=June 26, 2020
}}{{sps|{{subst:DATE}}|date=January 2024}}</ref><ref name="martin-GF">
{{cite web
 |author=martin
 |title=China, GitHub and the man-in-the-middle
 |url=https://en.greatfire.org/blog/2013/jan/china-github-and-man-middle
 |website=GreatFire
 |date=January 30, 2013
 |access-date=27 June 2015
 |archive-url=https://web.archive.org/web/20160819165216/https://en.greatfire.org/blog/2013/jan/china-github-and-man-middle
 |archive-date=19 August 2016
}}{{sps|{{subst:DATE}}|date=January 2024}}</ref><ref name="percy-GF">
{{cite web
 |url=https://en.greatfire.org/blog/2014/sep/authorities-launch-man-middle-attack-google
 |title=Authorities launch man-in-the-middle attack on Google
 |author=percy
 |date=September 4, 2014
 |website=GreatFire
 |access-date=June 26, 2020
}}{{sps|{{subst:DATE}}|date=January 2024}}</ref>

=== Public key infrastructure ===
One approach to prevent such attacks involves the use of a [[public key infrastructure]] (PKI); a set of roles, policies, and procedures needed to create, manage, distribute, use, store and [[certificate revocation|revoke]] digital certificates and manage public-key encryption. However, this has potential weaknesses.

For example, the certificate authority issuing the certificate must be trusted by all participating parties to have properly checked the identity of the key-holder, to have ensured the correctness of the public key when it issues a certificate, to be secure from computer piracy, and to have made arrangements with all participants to check all their certificates before protected communications can begin. [[Web browser]]s, for instance, are supplied with a long list of "self-signed identity certificates" from PKI providers – these are used to check the ''bona fides'' of the certificate authority and then, in a second step, the certificates of potential communicators. An attacker who could subvert one of those certificate authorities into issuing a certificate for a bogus public key could then mount a "man-in-the-middle" attack as easily as if the certificate scheme were not used at all. An attacker who penetrates an authority's servers and obtains its store of certificates and keys (public and private) would be able to spoof, masquerade, decrypt, and forge transactions without limit, assuming that they were able to place themselves in the communication stream.

Despite its theoretical and potential problems, Public key infrastructure is widely used. Examples include [[Transport Layer Security|TLS]] and its predecessor [[Transport Layer Security#SSL 1.0, 2.0, and 3.0|SSL]], which are commonly used to provide security for web browser transactions (for example, most websites utilize TLS for [[HTTPS]]).

Aside from the resistance to attack of a particular key pair, the security of the certification [[hierarchy]] must be considered when deploying public key systems. Some certificate authority – usually a purpose-built program running on a server computer – vouches for the identities assigned to specific private keys by producing a digital certificate. [[Digital certificate|Public key digital certificates]] are typically valid for several years at a time, so the associated private keys must be held securely over that time. When a private key used for certificate creation higher in the PKI server hierarchy is compromised, or accidentally disclosed, then a "[[man-in-the-middle attack]]" is possible, making any subordinate certificate wholly insecure.

===Unencrypted metadata===
Most of the available public-key encryption software does not conceal [[metadata]] in the message header, which might include the identities of the sender and recipient, the sending date, subject field, and the software they use etc.  Rather, only the body of the message is concealed and can only be decrypted with the private key of the intended recipient.  This means that a third party could construct quite a detailed model of participants in a communication network, along with the subjects being discussed, even if the message body itself is hidden.

However, there has been a recent demonstration of messaging with encrypted headers, which obscures the identities of the sender and recipient, and significantly reduces the available metadata to a third party.<ref>
{{cite arXiv
 |last1=Bjorgvinsdottir |first1=Hanna
 |last2=Bentley |first2=Phil
 |date=2021-06-24
 |title=Warp2: A Method of Email and Messaging with Encrypted Addressing and Headers
 |class=cs.CR
 |eprint=1411.6409
}}</ref>  The concept is based around an open repository containing separately encrypted metadata blocks and encrypted messages. Only the intended recipient is able to decrypt the metadata block, and having done so they can identify and download their messages and decrypt them.  Such a messaging system is at present in an experimental phase and not yet deployed.  Scaling this method would reveal to the third party only the inbox server being used by the recipient and the timestamp of sending and receiving.  The server could be shared by thousands of users, making social network modelling much more challenging.