Editing Public-key cryptography (section)

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