{
	"id": "4d1e372f-a85b-4d02-921d-ad226faf3c8a",
	"created_at": "2026-04-06T01:30:43.831304Z",
	"updated_at": "2026-04-10T03:23:38.777088Z",
	"deleted_at": null,
	"sha1_hash": "6d12ca43892acaea68c155d1f7baf77321060af0",
	"title": "Public-key cryptography",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 323851,
	"plain_text": "Public-key cryptography\r\nBy Contributors to Wikimedia projects\r\nPublished: 2001-11-09 · Archived: 2026-04-06 00:38:15 UTC\r\nAn unpredictable (typically large and random) number is used to begin generation of an acceptable\r\npair of keys suitable for use by an asymmetric key algorithm.\r\nIn this example the message is digitally signed with Alice's private key, but the message itself is not\r\nencrypted. 1) Alice signs a message with her private key. 2) Using Alice's public key, Bob can verify\r\nthat Alice sent the message and that the message has not been modified.\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 1 of 12\n\nIn the Diffie–Hellman key exchange scheme, each party generates a public/private key pair and\r\ndistributes the public key of the pair. After obtaining an authentic (n.b., this is critical) copy of each\r\nother's public keys, Alice and Bob can compute a shared secret offline. The shared secret can be\r\nused, for instance, as the key for a symmetric cipher.\r\nIn an asymmetric key encryption scheme, anyone can encrypt messages using a public key, but only\r\nthe holder of the paired private key can decrypt such a message. The security of the system depends\r\non the secrecy of the private key, which must not become known to any other.\r\nPublic-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of\r\nrelated keys. Each key pair consists of a public key and a corresponding private key.\r\n[1][2]\r\n Key pairs are\r\ngenerated with algorithms based on mathematical problems termed one-way functions. Security of public-key\r\ncryptography depends on keeping the private key secret; the public key can be openly distributed without\r\ncompromising security.\r\n[3]\r\n There are many kinds of public-key cryptosystems, with different security goals,\r\nincluding digital signature, Diffie–Hellman key exchange, public-key key encapsulation, and public-key\r\nencryption.\r\nPublic key algorithms are fundamental security primitives in modern cryptosystems, including applications and\r\nprotocols that offer assurance of the confidentiality and authenticity of electronic communications and data\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 2 of 12\n\nstorage. They underpin numerous Internet standards, such as Transport Layer Security (TLS), SSH, S/MIME, and\r\nPGP. Compared to symmetric cryptography, public-key cryptography can be too slow for many purposes,[4] so\r\nthese protocols often combine symmetric cryptography with public-key cryptography in hybrid cryptosystems.\r\nBefore the mid-1970s, all cipher systems used symmetric key algorithms, in which the same cryptographic key is\r\nused with the underlying algorithm by both the sender and the recipient, who must both keep the key secret. Of\r\nnecessity, the key in every such system had to be exchanged between the communicating parties in some secure\r\nway prior to any use of the system – for instance, via a secure channel. This requirement is never trivial and very\r\nrapidly becomes unmanageable as the number of participants increases, when secure channels are not available, or\r\nwhen (as is sensible cryptographic practice) keys are frequently changed. In particular, if messages are meant to be\r\nsecure from other users, a separate key is required for each possible pair of users.\r\nBy contrast, in a public-key cryptosystem, the public keys can be disseminated widely and openly, and only the\r\ncorresponding private keys need be kept secret.\r\nThe two best-known types of public key cryptography are digital signature and public-key encryption:\r\nIn a digital signature system, a sender can use a private key together with a message to create a signature.\r\nAnyone with the corresponding public key can verify whether the signature matches the message, but a\r\nforger who does not know the private key cannot find any message/signature pair that will pass verification\r\nwith the public key.\r\n[5][6][7]\r\nFor example, a software publisher can create a signature key pair and include the public key in software\r\ninstalled on computers. Later, the publisher can distribute an update to the software signed using the private\r\nkey, and any computer receiving an update can confirm it is genuine by verifying the signature using the\r\npublic key. As long as the software publisher keeps the private key secret, even if a forger can distribute\r\nmalicious updates to computers, they cannot convince the computers that any malicious updates are\r\ngenuine.\r\nIn a public-key encryption system, anyone with a public key can encrypt a message, yielding a ciphertext,\r\nbut only those who know the corresponding private key can decrypt the ciphertext to obtain the original\r\nmessage.[8]\r\nFor example, a journalist can publish the public key of an encryption key pair on a web site so that sources\r\ncan send secret messages to the news organization in ciphertext.\r\nOnly the journalist who knows the corresponding private key can decrypt the ciphertexts to obtain the\r\nsources' messages—an eavesdropper reading email on its way to the journalist cannot decrypt the\r\nciphertexts. However, public-key encryption does not conceal metadata like what computer a source used\r\nto send a message, when they sent it, or how long it is.[9][10][11][12] Public-key encryption on its own also\r\ndoes not tell the recipient anything about who sent a message[8]: 283 [13][14]—it just conceals the content of\r\nthe message.\r\nApplications built on public-key cryptography include authenticating web servers with TLS, digital cash,\r\npassword-authenticated key agreement, authenticating and concealing email content with OpenPGP or S/MIME,\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 3 of 12\n\nand time-stamping services and non-repudiation protocols.\r\nOne important issue is confidence/proof that a particular public key is authentic, i.e. that it is correct and belongs\r\nto the person or entity claimed, and has not been tampered with or replaced by some (perhaps malicious) third\r\nparty. There are several possible approaches, including:\r\nA public key infrastructure (PKI), in which one or more third parties – known as certificate authorities – certify\r\nownership of key pairs. TLS relies upon this. This implies that the PKI system (software, hardware, and\r\nmanagement) is trust-able by all involved.\r\nA \"web of trust\" decentralizes authentication by using individual endorsements of links between a user and the\r\npublic key belonging to that user. PGP uses this approach, in addition to lookup in the domain name system\r\n(DNS). The DKIM system for digitally signing emails also uses this approach.\r\nHybrid cryptosystems\r\n[edit]\r\nBecause asymmetric key algorithms are nearly always much more computationally intensive than symmetric ones,\r\nit is common to use a public/private asymmetric key-exchange algorithm to encrypt and exchange a symmetric\r\nkey, which is then used by symmetric-key cryptography to transmit data using the now-shared symmetric key for a\r\nsymmetric key encryption algorithm. PGP, SSH, and the SSL/TLS family of schemes use this procedure; they are\r\nthus called hybrid cryptosystems. The initial asymmetric cryptography-based key exchange to share a server-generated symmetric key from the server to client has the advantage of not requiring that a symmetric key be pre-shared manually, such as on printed paper or discs transported by a courier, while providing the higher data\r\nthroughput of symmetric key cryptography over asymmetric key cryptography for the remainder of the shared\r\nconnection.\r\nAs with all security-related systems, there are various potential weaknesses in public-key cryptography. Aside\r\nfrom poor choice of an asymmetric key algorithm (there are few that are widely regarded as satisfactory) or too\r\nshort a key length, the chief security risk is that the private key of a pair becomes known. All security of\r\nmessages, authentication, etc., encrypted with this private key will then be lost. This is commonly mitigated (such\r\nas in recent TLS schemes) by using Forward secrecy capable schemes that generate an ephemeral set of keys\r\nduring the communication which must also be known for the communication to be compromised.\r\nAdditionally, with the advent of quantum computing, many asymmetric key algorithms are considered vulnerable\r\nto attacks, and new quantum-resistant schemes are being developed to overcome the problem.[15][16]\r\nBeyond algorithmic or key-length weaknesses, some studies have noted risks when private key control is\r\ndelegated to third parties. Research on Uruguay’s implementation of Public Key Infrastructure under Law 18.600\r\nfound that centralized key custody by Trust Service Providers (TSPs) may weaken the principle of private-key\r\nsecrecy, increasing exposure to man-in-the-middle attacks and raising concerns about legal non-repudiation.[17]\r\nAll public key schemes are in theory susceptible to a \"brute-force key search attack\".[18] However, such an attack\r\nis impractical if the amount of computation needed to succeed – termed the \"work factor\" by Claude Shannon – is\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 4 of 12\n\nout of reach of all potential attackers. In many cases, the work factor can be increased by simply choosing a longer\r\nkey. But other algorithms may inherently have much lower work factors, making resistance to a brute-force attack\r\n(e.g., from longer keys) irrelevant. Some special and specific algorithms have been developed to aid in attacking\r\nsome public key encryption algorithms; both RSA and ElGamal encryption have known attacks that are much\r\nfaster than the brute-force approach.[citation needed] None of these are sufficiently improved to be actually practical,\r\nhowever.\r\nMajor weaknesses have been found for several formerly promising asymmetric key algorithms. The \"knapsack\r\npacking\" algorithm was found to be insecure after the development of a new attack.[19] As with all cryptographic\r\nfunctions, public-key implementations may be vulnerable to side-channel attacks that exploit information leakage\r\nto simplify the search for a secret key. These are often independent of the algorithm being used. Research is\r\nunderway to both discover, and to protect against, new attacks.\r\nAlteration of public keys\r\n[edit]\r\nAnother potential security vulnerability in using asymmetric keys is the possibility of a \"man-in-the-middle\"\r\nattack, in which the communication of public keys is intercepted by a third party (the \"man in the middle\") and\r\nthen modified to provide different public keys instead. Encrypted messages and responses must, in all instances,\r\nbe intercepted, decrypted, and re-encrypted by the attacker using the correct public keys for the different\r\ncommunication segments so as to avoid suspicion.[citation needed]\r\nA communication is said to be insecure where data is transmitted in a manner that allows for interception (also\r\ncalled \"sniffing\"). These terms refer to reading the sender's private data in its entirety. A communication is\r\nparticularly unsafe when interceptions can not be prevented or monitored by the sender.\r\n[20]\r\nA man-in-the-middle attack can be difficult to implement due to the complexities of modern security protocols.\r\nHowever, the task becomes simpler when a sender is using insecure media such as public networks, the Internet,\r\nor wireless communication. In these cases an attacker can compromise the communications infrastructure rather\r\nthan 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\r\nas it gets sent through the ISP's communications hardware; in properly implemented asymmetric key schemes, this\r\nis not a significant risk.[citation needed]\r\nIn some advanced man-in-the-middle attacks, one side of the communication will see the original data while the\r\nother will receive a malicious variant. Asymmetric man-in-the-middle attacks can prevent users from realizing\r\ntheir connection is compromised. This remains so even when one user's data is known to be compromised because\r\nthe data appears fine to the other user. This can lead to confusing disagreements between users such as \"it must be\r\non your end!\" when neither user is at fault. Hence, man-in-the-middle attacks are only fully preventable when the\r\ncommunications infrastructure is physically controlled by one or both parties; such as via a wired route inside the\r\nsender's own building. In summation, public keys are easier to alter when the communications hardware used by a\r\nsender is controlled by an attacker.\r\n[21][22][23]\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 5 of 12\n\nPublic key infrastructure\r\n[edit]\r\nOne approach to prevent such attacks involves the use of a public key infrastructure (PKI); a set of roles, policies,\r\nand procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. However, this has potential weaknesses.\r\nFor example, the certificate authority issuing the certificate must be trusted by all participating parties to have\r\nproperly checked the identity of the key-holder, to have ensured the correctness of the public key when it issues a\r\ncertificate, to be secure from computer piracy, and to have made arrangements with all participants to check all\r\ntheir certificates before protected communications can begin. Web browsers, for instance, are supplied with a long\r\nlist of \"self-signed identity certificates\" from PKI providers – these are used to check the bona fides of the\r\ncertificate authority and then, in a second step, the certificates of potential communicators. An attacker who could\r\nsubvert one of those certificate authorities into issuing a certificate for a bogus public key could then mount a\r\n\"man-in-the-middle\" attack as easily as if the certificate scheme were not used at all. An attacker who penetrates\r\nan authority's servers and obtains its store of certificates and keys (public and private) would be able to spoof,\r\nmasquerade, decrypt, and forge transactions without limit, assuming that they were able to place themselves in the\r\ncommunication stream.\r\nDespite its theoretical and potential problems, Public key infrastructure is widely used. Examples include TLS and\r\nits predecessor SSL, which are commonly used to provide security for web browser transactions (for example,\r\nmost websites utilize TLS for HTTPS).\r\nAside from the resistance to attack of a particular key pair, the security of the certification hierarchy must be\r\nconsidered when deploying public key systems. Some certificate authority – usually a purpose-built program\r\nrunning on a server computer – vouches for the identities assigned to specific private keys by producing a digital\r\ncertificate. Public key digital certificates are typically valid for several years at a time, so the associated private\r\nkeys must be held securely over that time. When a private key used for certificate creation higher in the PKI\r\nserver hierarchy is compromised, or accidentally disclosed, then a \"man-in-the-middle attack\" is possible, making\r\nany subordinate certificate wholly insecure.\r\nUnencrypted metadata\r\n[edit]\r\nMost of the available public-key encryption software does not conceal metadata in the message header, which\r\nmight include the identities of the sender and recipient, the sending date, subject field, and the software they use\r\netc. Rather, only the body of the message is concealed and can only be decrypted with the private key of the\r\nintended recipient. This means that a third party could construct quite a detailed model of participants in a\r\ncommunication network, along with the subjects being discussed, even if the message body itself is hidden.\r\nHowever, there has been a recent demonstration of messaging with encrypted headers, which obscures the\r\nidentities of the sender and recipient, and significantly reduces the available metadata to a third party.\r\n[24]\r\n The\r\nconcept is based around an open repository containing separately encrypted metadata blocks and encrypted\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 6 of 12\n\nmessages. Only the intended recipient is able to decrypt the metadata block, and having done so they can identify\r\nand download their messages and decrypt them. Such a messaging system is at present in an experimental phase\r\nand not yet deployed. Scaling this method would reveal to the third party only the inbox server being used by the\r\nrecipient and the timestamp of sending and receiving. The server could be shared by thousands of users, making\r\nsocial network modelling much more challenging.\r\nDuring the early history of cryptography, two parties would rely upon a key that they would exchange by means of\r\na secure, but non-cryptographic, method such as a face-to-face meeting, or a trusted courier. This key, which both\r\nparties must then keep absolutely secret, could then be used to exchange encrypted messages. A number of\r\nsignificant practical difficulties arise with this approach to distributing keys.\r\nIn his 1874 book The Principles of Science, William Stanley Jevons wrote:[25]\r\nCan the reader say what two numbers multiplied together will produce the number 8,616,460,799?\r\n[26]\r\n I\r\nthink it unlikely that anyone but myself will ever know.\r\n[25]\r\nHere he described the relationship of one-way functions to cryptography, and went on to discuss specifically the\r\nfactorization problem used to create a trapdoor function. In July 1996, mathematician Solomon W. Golomb said:\r\n\"Jevons anticipated a key feature of the RSA Algorithm for public key cryptography, although he certainly did not\r\ninvent the concept of public key cryptography.\"[27]\r\nClassified discovery\r\n[edit]\r\nIn 1970, James H. Ellis, a British cryptographer at the UK Government Communications Headquarters (GCHQ),\r\nconceived of the possibility of \"non-secret encryption\", (now called public key cryptography), but could see no\r\nway to implement it.[28][29][30]\r\nIn 1973, his colleague Clifford Cocks implemented what has become known as the RSA encryption algorithm,\r\ngiving a practical method of \"non-secret encryption\", and in 1974 another GCHQ mathematician and\r\ncryptographer, Malcolm J. Williamson, developed what is now known as Diffie–Hellman key exchange. The\r\nscheme was also passed to the US's National Security Agency.\r\n[31]\r\n Both organisations had a military focus and\r\nonly limited computing power was available in any case; the potential of public key cryptography remained\r\nunrealised by either organization. According to Ralph Benjamin:\r\nI judged it most important for military use ... if you can share your key rapidly and electronically, you\r\nhave a major advantage over your opponent. Only at the end of the evolution from Berners-Lee\r\ndesigning an open internet architecture for CERN, its adaptation and adoption for the Arpanet ... did\r\npublic key cryptography realise its full potential.[31]\r\nThese discoveries were not publicly acknowledged until the research was declassified by the British government\r\nin 1997.[32]\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 7 of 12\n\nIn 1976, an asymmetric key cryptosystem was published by Whitfield Diffie and Martin Hellman who, influenced\r\nby Ralph Merkle's work on public key distribution, disclosed a method of public key agreement. This method of\r\nkey exchange, which uses exponentiation in a finite field, came to be known as Diffie–Hellman key exchange.\r\n[33]\r\nThis was the first published practical method for establishing a shared secret-key over an authenticated (but not\r\nconfidential) communications channel without using a prior shared secret. Merkle's \"public key-agreement\r\ntechnique\" became known as Merkle's Puzzles, and was invented in 1974 and only published in 1978. This makes\r\nasymmetric encryption a rather new field in cryptography although cryptography itself dates back more than 2,000\r\nyears.[34]\r\nIn 1977, a generalization of Cocks's scheme was independently invented by Ron Rivest, Adi Shamir and Leonard\r\nAdleman, all then at MIT. The latter authors published their work in 1978 in Martin Gardner's Scientific American\r\ncolumn, and the algorithm came to be known as RSA, from their initials.[35] RSA uses exponentiation modulo a\r\nproduct of two very large primes, to encrypt and decrypt, performing both public key encryption and public key\r\ndigital signatures. Its security is connected to the extreme difficulty of factoring large integers, a problem for\r\nwhich there is no known efficient general technique. A description of the algorithm was published in the\r\nMathematical Games column in the August 1977 issue of Scientific American.\r\n[36]\r\nSince the 1970s, a large number and variety of encryption, digital signature, key agreement, and other techniques\r\nhave been developed, including the Rabin signature, ElGamal encryption, DSA and ECC.\r\nExamples of well-regarded asymmetric key techniques for varied purposes include:\r\nDiffie–Hellman key exchange protocol\r\nDSS (Digital Signature Standard), which incorporates the Digital Signature Algorithm\r\nElGamal\r\nElliptic-curve cryptography\r\nElliptic Curve Digital Signature Algorithm (ECDSA)\r\nElliptic-curve Diffie–Hellman (ECDH)\r\nEd25519 and Ed448 (EdDSA)\r\nX25519 and X448 (ECDH/EdDH)\r\nVarious password-authenticated key agreement techniques\r\nPaillier cryptosystem\r\nRSA encryption algorithm (PKCS#1)\r\nCramer–Shoup cryptosystem\r\nYAK authenticated key agreement protocol\r\nExamples of asymmetric key algorithms not yet widely adopted include:\r\nNTRUEncrypt cryptosystem\r\nKyber\r\nMcEliece cryptosystem\r\nExamples of notable – yet insecure – asymmetric key algorithms include:\r\nMerkle–Hellman knapsack cryptosystem\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 8 of 12\n\nExamples of protocols using asymmetric key algorithms include:\r\nS/MIME\r\nGPG, an implementation of OpenPGP, and an Internet Standard\r\nEMV, EMV Certificate Authority\r\nIPsec\r\nPGP\r\nZRTP, a secure VoIP protocol\r\nTransport Layer Security standardized by IETF and its predecessor Secure Socket Layer\r\nSILC\r\nSSH\r\nBitcoin\r\nOff-the-Record Messaging\r\nBooks on cryptography\r\nGNU Privacy Guard\r\nIdentity-based encryption (IBE)\r\nKey escrow\r\nKey-agreement protocol\r\nPGP word list\r\nPost-quantum cryptography\r\nPretty Good Privacy\r\nPseudonym\r\nPublic key fingerprint\r\nPublic key infrastructure (PKI)\r\nQuantum computing\r\nQuantum cryptography\r\nSecure Shell (SSH)\r\nSymmetric-key algorithm\r\nThreshold cryptosystem\r\nWeb of trust\r\n1. ^ R. Shirey (August 2007). Internet Security Glossary, Version 2. Network Working Group.\r\ndoi:10.17487/RFC4949. RFC 4949. Informational.\r\n2. ^ Bernstein, Daniel J.; Lange, Tanja (14 September 2017). \"Post-quantum cryptography\". Nature. 549\r\n(7671): 188–194. Bibcode:2017Natur.549..188B. doi:10.1038/nature23461. ISSN 0028-0836.\r\nPMID 28905891. S2CID 4446249.\r\n3. ^ Stallings, William (3 May 1990). Cryptography and Network Security: Principles and Practice. Prentice\r\nHall. p. 165. ISBN 9780138690175.\r\n4. ^ Alvarez, Rafael; Caballero-Gil, Cándido; Santonja, Juan; Zamora, Antonio (27 June 2017). \"Algorithms\r\nfor Lightweight Key Exchange\". Sensors. 17 (7): 1517. doi:10.3390/s17071517. ISSN 1424-8220.\r\nPMC 5551094. PMID 28654006.\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 9 of 12\n\n5. ^ Menezes, Alfred J.; van Oorschot, Paul C.; Vanstone, Scott A. (October 1996). \"Chapter 8: Public-key\r\nencryption\". Handbook of Applied Cryptography (PDF). CRC Press. pp. 425–488. ISBN 0-8493-8523-7.\r\nRetrieved 8 October 2022.\r\n6. ^ Bernstein, Daniel J. (1 May 2008). \"Protecting communications against forgery\". Algorithmic Number\r\nTheory (PDF). Vol. 44. MSRI Publications. §5: Public-key signatures, pp. 543–545. Retrieved 8 October\r\n2022.\r\n7. ^ Bellare, Mihir; Goldwasser, Shafi (July 2008). \"Chapter 10: Digital signatures\". Lecture Notes on\r\nCryptography (PDF). p. 168. Archived (PDF) from the original on 20 April 2022. Retrieved 11 June 2023.\r\n8. ^ Jump up to: a\r\n \r\nb\r\n Menezes, Alfred J.; van Oorschot, Paul C.; Vanstone, Scott A. (October 1996). \"8:\r\nPublic-key encryption\". Handbook of Applied Cryptography (PDF). CRC Press. pp. 283–319. ISBN 0-\r\n8493-8523-7. Retrieved 8 October 2022.\r\n9. ^ Danezis, George; Diaz, Claudia; Syverson, Paul (2010). \"Chapter 13: Anonymous Communication\". In\r\nRosenberg, Burton (ed.). Handbook of Financial Cryptography and Security (PDF). Chapman \u0026\r\nHall/CRC. pp. 341–390. ISBN 978-1420059816. “Since PGP, beyond compressing the messages, does not\r\nmake any further attempts to hide their size, it is trivial to follow a message in the network just by\r\nobserving its length.”\r\n10. ^ Rackoff, Charles; Simon, Daniel R. (1993). \"Cryptographic defense against traffic analysis\".\r\nProceedings of the twenty-fifth annual ACM symposium on Theory of Computing. STOC '93: ACM\r\nSymposium on the Theory of Computing. Association for Computing Machinery. pp. 672–681.\r\ndoi:10.1145/167088.167260. “Now, certain types of information cannot reasonably be assumed to be\r\nconcealed. For instance, an upper bound on the total volume of a party's sent or received communication\r\n(of any sort) is obtainable by anyone with the resources to examine all possible physical communication\r\nchannels available to that party.”\r\n11. ^ Karger, Paul A. (May 1977). \"11: Limitations of End-to-End Encryption\". Non-Discretionary Access\r\nControl for Decentralized Computing Systems (S.M. thesis). Laboratory for Computer Science,\r\nMassachusetts Institute of Technology. hdl:1721.1/149471. “The scenario just described would seem to be\r\nsecure, because all data is encrypted before being passed to the communications processors. However,\r\ncertain control information must be passed in cleartext from the host to the communications processor to\r\nallow the network to function. This control information consists of the destination address for the packet,\r\nthe length of the packet, and the time between successive packet transmissions.”\r\n12. ^ Chaum, David L. (February 1981). Rivest, R. (ed.). \"Untraceable Electronic Mail, Return Addresses, and\r\nDigital Pseudonyms\". Communications of the ACM. 24 (2). Association for Computing Machinery.\r\n“Recently, some new solutions to the \"key distribution problem\" (the problem of providing each\r\ncommunicant with a secret key) have been suggested, under the name of public key cryptography. Another\r\ncryptographic problem, the \"traffic analysis problem\" (the problem of keeping confidential who converses\r\nwith whom, and when they converse), will become increasingly important with the growth of electronic\r\nmail.”\r\n13. ^ Davis, Don (2001). \"Defective Sign \u0026 Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML\".\r\nProceedings of the 2001 USENIX Annual Technical Conference. USENIX. pp. 65–78. “Why is naïve Sign\r\n\u0026 Encrypt insecure? Most simply, S\u0026E is vulnerable to \"surreptitious forwarding:\" Alice signs \u0026 encrypts\r\nfor Bob's eyes, but Bob re-encrypts Alice's signed message for Charlie to see. In the end, Charlie believes\r\nAlice wrote to him directly, and can't detect Bob's subterfuge.”\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 10 of 12\n\n14. ^ An, Jee Hea (12 September 2001). Authenticated Encryption in the Public-Key Setting: Security Notions\r\nand Analyses (Technical report). IACR Cryptology ePrint Archive. 2001/079. Retrieved 24 November 2024.\r\n15. ^ Escribano Pablos, José Ignacio; González Vasco, María Isabel (April 2023). \"Secure post-quantum\r\ngroup key exchange: Implementing a solution based on Kyber\". IET Communications. 17 (6): 758–773.\r\ndoi:10.1049/cmu2.12561. hdl:10016/37141. ISSN 1751-8628. S2CID 255650398.\r\n16. ^ Stohrer, Christian; Lugrin, Thomas (2023), Mulder, Valentin; Mermoud, Alain; Lenders, Vincent;\r\nTellenbach, Bernhard (eds.), \"Asymmetric Encryption\", Trends in Data Protection and Encryption\r\nTechnologies, Cham: Springer Nature Switzerland, pp. 11–14, doi:10.1007/978-3-031-33386-6_3,\r\nISBN 978-3-031-33386-6 {{citation}} : CS1 maint: work parameter with ISBN (link)\r\n17. ^ Sabiguero, Ariel; Vicente, Alfonso; Esnal, Gonzalo (November 2024). \"Let There Be Trust\". 2024 IEEE\r\nURUCON. doi:10.1109/URUCON63440.2024.10850093.\r\n18. ^ Paar, Christof; Pelzl, Jan; Preneel, Bart (2010). Understanding Cryptography: A Textbook for Students\r\nand Practitioners. Springer. ISBN 978-3-642-04100-6.\r\n19. ^ Shamir, Adi (November 1982). \"A polynomial time algorithm for breaking the basic Merkle-Hellman\r\ncryptosystem\". 23rd Annual Symposium on Foundations of Computer Science (SFCS 1982). pp. 145–152.\r\ndoi:10.1109/SFCS.1982.5.\r\n20. ^ Tunggal, Abi (20 February 2020). \"What Is a Man-in-the-Middle Attack and How Can It Be Prevented –\r\nWhat is the difference between a man-in-the-middle attack and sniffing?\". UpGuard. Retrieved 26 June\r\n2020.\r\n[self-published source?]\r\n21. ^ Tunggal, Abi (20 February 2020). \"What Is a Man-in-the-Middle Attack and How Can It Be Prevented -\r\nWhere do man-in-the-middle attacks happen?\". UpGuard. Retrieved 26 June 2020.\r\n[self-published source?]\r\n22. ^ martin (30 January 2013). \"China, GitHub and the man-in-the-middle\". GreatFire. Archived from the\r\noriginal on 19 August 2016. Retrieved 27 June 2015.\r\n[self-published source?]\r\n23. ^ percy (4 September 2014). \"Authorities launch man-in-the-middle attack on Google\". GreatFire.\r\nRetrieved 26 June 2020.\r\n[self-published source?]\r\n24. ^ Bjorgvinsdottir, Hanna; Bentley, Phil (24 June 2021). \"Warp2: A Method of Email and Messaging with\r\nEncrypted Addressing and Headers\". arXiv:1411.6409 [cs.CR].\r\n25. ^ Jump up to: a\r\n \r\nb\r\n Jevons, W.S. (1874). The Principles of Science: A Treatise on Logic and Scientific\r\nMethod. Macmillan \u0026 Co. p. 141. Retrieved 18 January 2024.\r\n26. ^ Weisstein, E.W. (2024). \"Jevons' Number\". MathWorld. Retrieved 18 January 2024.\r\n27. ^ Golob, Solomon W. (1996). \"On Factoring Jevons' Number\". Cryptologia. 20 (3): 243.\r\ndoi:10.1080/0161-119691884933. S2CID 205488749.\r\n28. ^ Ellis, James H. (January 1970). \"The Possibility of Secure Non-secret Digital Encryption\" (PDF).\r\nCryptoCellar. Retrieved 18 January 2024.\r\n29. ^ Ellis, James H. (January 1970). \"The Possibility of Secure Non-secret Digital Encryption\". The George\r\nWashington University. Retrieved 8 December 2025.\r\n30. ^ Sawer, Patrick (11 March 2016). \"The unsung genius who secured Britain's computer defences and\r\npaved the way for safe online shopping\". The Telegraph.\r\n31. ^ Jump up to: a\r\n \r\nb\r\n Espiner, Tom (26 October 2010). \"GCHQ pioneers on birth of public key crypto\". ZDNet.\r\n32. ^ Singh, Simon (1999). The Code Book. Doubleday. pp. 279–292.\r\n33. ^ Diffie, Whitfield; Hellman, Martin E. (November 1976). \"New Directions in Cryptography\" (PDF). IEEE\r\nTransactions on Information Theory. 22 (6): 644–654. Bibcode:1976ITIT...22..644D.\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 11 of 12\n\nCiteSeerX 10.1.1.37.9720. doi:10.1109/TIT.1976.1055638. Archived (PDF) from the original on 29\r\nNovember 2014.\r\n34. ^ \"Asymmetric encryption\". IONOS Digitalguide. Retrieved 9 June 2022.\r\n35. ^ Rivest, R.; Shamir, A.; Adleman, L. (February 1978). \"A Method for Obtaining Digital Signatures and\r\nPublic-Key Cryptosystems\" (PDF). Communications of the ACM. 21 (2): 120–126.\r\nCiteSeerX 10.1.1.607.2677. doi:10.1145/359340.359342. S2CID 2873616. Archived from the original\r\n(PDF) on 17 December 2008. Retrieved 15 November 2019.\r\n36. ^ Robinson, Sara (June 2003). \"Still Guarding Secrets after Years of Attacks, RSA Earns Accolades for its\r\nFounders\" (PDF). SIAM News. 36 (5).\r\nHirsch, Frederick J. \"SSL/TLS Strong Encryption: An Introduction\". Apache HTTP Server. Retrieved 17\r\nApril 2013.. The first two sections contain a very good introduction to public-key cryptography.\r\nFerguson, Niels; Schneier, Bruce (2003). Practical Cryptography. Wiley. ISBN 0-471-22357-3.\r\nKatz, Jon; Lindell, Y. (2007). Introduction to Modern Cryptography. CRC Press. ISBN 978-1-58488-551-1.\r\nMenezes, A. J.; van Oorschot, P. C.; Vanstone, Scott A. (1997). Handbook of Applied Cryptography. Taylor\r\n\u0026 Francis. ISBN 0-8493-8523-7.\r\nIEEE 1363: Standard Specifications for Public-Key Cryptography\r\nChristof Paar, Jan Pelzl, \"Introduction to Public-Key Cryptography\", Chapter 6 of \"Understanding\r\nCryptography, A Textbook for Students and Practitioners\". (companion web site contains online\r\ncryptography course that covers public-key cryptography), Springer, 2009.\r\nSalomaa, Arto (1996). Public-Key Cryptography (2 ed.). Berlin: Springer. 275. doi:10.1007/978-3-662-\r\n03269-5. ISBN 978-3-662-03269-5. S2CID 24751345.\r\nOral history interview with Martin Hellman, Charles Babbage Institute, University of Minnesota. Leading\r\ncryptography scholar Martin Hellman discusses the circumstances and fundamental insights of his\r\ninvention of public key cryptography with collaborators Whitfield Diffie and Ralph Merkle at Stanford\r\nUniversity in the mid-1970s.\r\nAn account of how GCHQ kept their invention of PKE secret until 1997\r\nSource: https://en.wikipedia.org/wiki/Public-key_cryptography\r\nhttps://en.wikipedia.org/wiki/Public-key_cryptography\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://en.wikipedia.org/wiki/Public-key_cryptography"
	],
	"report_names": [
		"Public-key_cryptography"
	],
	"threat_actors": [
		{
			"id": "5d2bd376-fcdc-4c6a-bc2c-17ebbb5b81a4",
			"created_at": "2022-10-25T16:07:23.667223Z",
			"updated_at": "2026-04-10T02:00:04.705778Z",
			"deleted_at": null,
			"main_name": "GCHQ",
			"aliases": [
				"Government Communications Headquarters",
				"Operation Socialist"
			],
			"source_name": "ETDA:GCHQ",
			"tools": [
				"Prax",
				"Regin",
				"WarriorPride"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775439043,
	"ts_updated_at": 1775791418,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6d12ca43892acaea68c155d1f7baf77321060af0.pdf",
		"text": "https://archive.orkl.eu/6d12ca43892acaea68c155d1f7baf77321060af0.txt",
		"img": "https://archive.orkl.eu/6d12ca43892acaea68c155d1f7baf77321060af0.jpg"
	}
}