Hubbry Logo
Public-key cryptographyPublic-key cryptographyMain
Open search
Public-key cryptography
Community hub
Public-key cryptography
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Public-key cryptography
Public-key cryptography
Public-key cryptography
View on Wikipedia
from Wikipedia

An unpredictable (typically large and random) number is used to begin generation of an acceptable pair of keys suitable for use by an asymmetric key algorithm.
In this example the message is digitally signed with Alice's private key, but the message itself is not encrypted. 1) Alice signs a message with her private key. 2) Using Alice's public key, Bob can verify that Alice sent the message and that the message has not been modified.
In the Diffie–Hellman key exchange scheme, each party generates a public/private key pair and distributes the public key of the pair. After obtaining an authentic (n.b., this is critical) copy of each other's public keys, Alice and Bob can compute a shared secret offline. The shared secret can be used, for instance, as the key for a symmetric cipher.
In an asymmetric key encryption scheme, anyone can encrypt messages using a public key, but only the holder of the paired private key can decrypt such a message. The security of the system depends on the secrecy of the private key, which must not become known to any other.

Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys. Each key pair consists of a public key and a corresponding private key.[1][2] Key pairs are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public-key cryptography depends on keeping the private key secret; the public key can be openly distributed without compromising security.[3] There are many kinds of public-key cryptosystems, with different security goals, including digital signature, Diffie–Hellman key exchange, public-key key encapsulation, and public-key encryption.

Public key algorithms are fundamental security primitives in modern cryptosystems, including applications and protocols that offer assurance of the confidentiality and authenticity of electronic communications and data storage. They underpin numerous Internet standards, such as Transport Layer Security (TLS), SSH, S/MIME, and PGP. Compared to symmetric cryptography, public-key cryptography can be too slow for many purposes,[4] so these protocols often combine symmetric cryptography with public-key cryptography in hybrid cryptosystems.

Description

[edit]

Before the mid-1970s, all cipher systems used symmetric key algorithms, in which the same cryptographic key is used with the underlying algorithm by both the sender and the recipient, who must both keep it secret. Of necessity, the key in every such system had to be exchanged between the communicating parties in some secure way prior to any use of the system – for instance, via a secure channel. This requirement is never trivial and very rapidly becomes unmanageable as the number of participants increases, or when secure channels are not available, or when (as is sensible cryptographic practice) keys are frequently changed. In particular, if messages are meant to be secure from other users, a separate key is required for each possible pair of users.

By contrast, in a public-key cryptosystem, the public keys can be disseminated widely and openly, and only the corresponding private keys need be kept secret.

The two best-known types of public key cryptography are digital signature and public-key encryption:

  • In a digital signature system, a sender can use a private key together with a message to create a signature. Anyone with the corresponding public key can verify whether the signature matches the message, but a forger who does not know the private key cannot find any message/signature pair that will pass verification with the public key.[5][6][7]

    For example, a software publisher can create a signature key pair and include the public key in software installed on computers. Later, the publisher can distribute an update to the software signed using the private key, and any computer receiving an update can confirm it is genuine by verifying the signature using the public key. As long as the software publisher keeps the private key secret, even if a forger can distribute malicious updates to computers, they cannot convince the computers that any malicious updates are genuine.

  • In a public-key encryption system, anyone with a public key can encrypt a message, yielding a ciphertext, but only those who know the corresponding private key can decrypt the ciphertext to obtain the original message.[8]

    For example, a journalist can publish the public key of an encryption key pair on a web site so that sources can send secret messages to the news organization in ciphertext.

    Only the journalist who knows the corresponding private key can decrypt the ciphertexts to obtain the sources' messages—an eavesdropper reading email on its way to the journalist cannot decrypt the ciphertexts. However, public-key encryption does not conceal metadata like what computer a source used to send a message, when they sent it, or how long it is.[9][10][11][12] Public-key encryption on its own also does not tell the recipient anything about who sent a message[8]: 283 [13][14]—it just conceals the content of the message.

Applications built on public-key cryptography include authenticating web servers with TLS, digital cash, password-authenticated key agreement, authenticating and concealing email content with OpenPGP or S/MIME, and time-stamping services and non-repudiation protocols.

One important issue is confidence/proof that a particular public key is authentic, i.e. that it is correct and belongs to the person or entity claimed, and has not been tampered with or replaced by some (perhaps malicious) third party. There are several possible approaches, including:

A public key infrastructure (PKI), in which one or more third parties – known as certificate authorities – certify ownership of key pairs. TLS relies upon this. This implies that the PKI system (software, hardware, and management) is trust-able by all involved.

A "web of trust" decentralizes authentication by using individual endorsements of links between a user and the public key belonging to that user. PGP uses this approach, in addition to lookup in the domain name system (DNS). The DKIM system for digitally signing emails also uses this approach.

Hybrid cryptosystems

[edit]

Because asymmetric key algorithms are nearly always much more computationally intensive than symmetric ones, it is common to use a public/private asymmetric key-exchange algorithm to encrypt and exchange a symmetric key, which is then used by symmetric-key cryptography to transmit data using the now-shared symmetric key for a symmetric key encryption algorithm. PGP, SSH, and the SSL/TLS family of schemes use this procedure; they are thus 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 throughput of symmetric key cryptography over asymmetric key cryptography for the remainder of the shared connection.

Weaknesses

[edit]

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., encrypted with this private key will then be lost. This is commonly mitigated (such as in recent TLS schemes) by using Forward secrecy capable schemes that generate an ephemeral set of keys during the communication which must also be known for the communication to be compromised.

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.[15][16]

Beyond algorithmic or key-length weaknesses, some studies have noted risks when private key control is delegated to third parties. Research on Uruguay’s implementation of Public Key Infrastructure under Law 18.600 found that centralized key custody by Trust Service Providers (TSPs) may weaken the principle of private-key secrecy, increasing exposure to man-in-the-middle attacks and raising concerns about legal non-repudiation.[17]

Algorithms

[edit]

All public key schemes are in theory susceptible to a "brute-force key search attack".[18] 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 and ElGamal encryption have known attacks that are much faster than the brute-force approach.[citation needed] None of these are sufficiently improved to be actually practical, however.

Major weaknesses have been found for several formerly promising asymmetric key algorithms. The "knapsack packing" algorithm was found to be insecure after the development of a new attack.[19] As with all cryptographic functions, public-key implementations may be vulnerable to side-channel attacks 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

[edit]

Another potential security vulnerability in using asymmetric keys is the possibility of a "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]

A communication is said to be insecure where data is transmitted in a manner that allows for interception (also called "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.[20]

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]

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.[21][22][23]

Public key infrastructure

[edit]

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 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 browsers, 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 TLS and its predecessor 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. 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

[edit]

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

History

[edit]

During the early history of cryptography, two parties would rely upon a key that they would exchange by means of a secure, but non-cryptographic, method such as a face-to-face meeting, or a trusted courier. This key, which both parties must then keep absolutely secret, could then be used to exchange encrypted messages. A number of significant practical difficulties arise with this approach to distributing keys.

Anticipation

[edit]

In his 1874 book The Principles of Science, William Stanley Jevons wrote:[25]

Can the reader say what two numbers multiplied together will produce the number 8616460799?[26] I think it unlikely that anyone but myself will ever know.[25]

Here he described the relationship of one-way functions to cryptography, and went on to discuss specifically the factorization problem used to create a trapdoor function. In July 1996, mathematician Solomon W. Golomb said: "Jevons anticipated a key feature of the RSA Algorithm for public key cryptography, although he certainly did not invent the concept of public key cryptography."[27]

Classified discovery

[edit]

In 1970, James H. Ellis, a British cryptographer at the UK Government Communications Headquarters (GCHQ), conceived of the possibility of "non-secret encryption", (now called public key cryptography), but could see no way to implement it.[28][29]

In 1973, his colleague Clifford Cocks implemented what has become known as the RSA encryption algorithm, giving a practical method of "non-secret encryption", and in 1974 another GCHQ mathematician and cryptographer, Malcolm J. Williamson, developed what is now known as Diffie–Hellman key exchange. The scheme was also passed to the US's National Security Agency.[30] Both organisations had a military focus and only limited computing power was available in any case; the potential of public key cryptography remained unrealised by either organization. According to Ralph Benjamin:

I judged it most important for military use ... if you can share your key rapidly and electronically, you have a major advantage over your opponent. Only at the end of the evolution from Berners-Lee designing an open internet architecture for CERN, its adaptation and adoption for the Arpanet ... did public key cryptography realise its full potential.[30]

These discoveries were not publicly acknowledged until the research was declassified by the British government in 1997.[31]

Public discovery

[edit]

In 1976, an asymmetric key cryptosystem was published by Whitfield Diffie and Martin Hellman who, influenced by Ralph Merkle's work on public key distribution, disclosed a method of public key agreement. This method of key exchange, which uses exponentiation in a finite field, came to be known as Diffie–Hellman key exchange.[32] This was the first published practical method for establishing a shared secret-key over an authenticated (but not confidential) communications channel without using a prior shared secret. Merkle's "public key-agreement technique" became known as Merkle's Puzzles, and was invented in 1974 and only published in 1978. This makes asymmetric encryption a rather new field in cryptography although cryptography itself dates back more than 2,000 years.[33]

In 1977, a generalization of Cocks's scheme was independently invented by Ron Rivest, Adi Shamir and Leonard Adleman, all then at MIT. The latter authors published their work in 1978 in Martin Gardner's Scientific American column, and the algorithm came to be known as RSA, from their initials.[34] RSA uses exponentiation modulo a product of two very large primes, to encrypt and decrypt, performing both public key encryption and public key digital signatures. Its security is connected to the extreme difficulty of factoring large integers, a problem for which there is no known efficient general technique. A description of the algorithm was published in the Mathematical Games column in the August 1977 issue of Scientific American.[35]

Since the 1970s, a large number and variety of encryption, digital signature, key agreement, and other techniques have been developed, including the Rabin signature, ElGamal encryption, DSA and ECC.

Examples

[edit]

Examples of well-regarded asymmetric key techniques for varied purposes include:

Examples of asymmetric key algorithms not yet widely adopted include:

Examples of notable – yet insecure – asymmetric key algorithms include:

Examples of protocols using asymmetric key algorithms include:

See also

[edit]

References

[edit]

Sources

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

Public-key cryptography

View on Grokipedia
from Grokipedia
Public-key cryptography, also known as asymmetric cryptography, is a class of cryptographic algorithms that utilize a pair of related keys—a public key, which can be openly shared, and a private key, which must remain secret—to perform encryption, decryption, digital signing, and verification operations. The public key is used by anyone to encrypt messages or verify signatures intended for the key owner, while only the private key holder can decrypt those messages or produce valid signatures, with the relationship between the keys designed such that deriving the private key from the public key is computationally infeasible. This approach addresses the key distribution challenges of symmetric cryptography by enabling secure communication over untrusted networks without requiring parties to exchange secrets in advance. The foundational ideas of public-key cryptography emerged in the mid-1970s amid growing concerns over secure data transmission in computer networks. In their 1976 paper "New Directions in Cryptography," and Martin E. Hellman introduced the of asymmetric key pairs, proposing a system where encryption keys could be publicly listed in directories, allowing any user to securely send encrypted messages to another without prior coordination or secure channels for . This innovation built on earlier theoretical work in but shifted focus toward practical, computationally secure systems resistant to . Independently, in 1977, Ronald L. Rivest, , and Leonard M. Adleman published their RSA algorithm, the first viable implementation of a public-key , relying on the mathematical difficulty of factoring the product of two large prime numbers to ensure security. Public-key cryptography underpins essential security mechanisms in digital systems, including confidentiality via encryption of sensitive data, authentication to verify identities, integrity to detect tampering, and non-repudiation to prevent denial of actions through digital signatures. It facilitates key establishment protocols, such as Diffie-Hellman key agreement, for deriving shared symmetric keys over public channels, and supports public key infrastructures (PKI) that issue and manage digital certificates binding public keys to verified entities via trusted certification authorities. Widely deployed in protocols like Transport Layer Security (TLS) for web browsing, Secure/Multipurpose Internet Mail Extensions (S/MIME) for email, and virtual private networks (VPNs), it enables scalable secure transactions in e-commerce, government services, and enterprise networks, with standards like RSA and elliptic curve cryptography (ECC) providing varying levels of security based on key sizes (e.g., 2048-bit RSA for at least 112 bits of security). As computational threats evolve, including those from quantum computing, ongoing standardization efforts emphasize robust key management and migration to post-quantum alternatives while maintaining compatibility with existing infrastructures.

Fundamentals

Definition and Principles

Public-key cryptography, also known as asymmetric cryptography, is a cryptographic that utilizes a pair of related keys—a public key and a private key—to secure communications and data. Unlike symmetric , which relies on a single shared secret key for both and decryption, public-key cryptography employs distinct keys for these operations: the public key is freely distributed and used for or verification, while the private key is kept secret and used for decryption or generation. This asymmetry ensures that the private key cannot be feasibly derived from the public key, providing a foundation for secure interactions without the need for prior secret key exchange. The core principles of public-key cryptography revolve around achieving key security objectives through the key pair mechanism. Confidentiality is ensured by encrypting messages with the recipient's public key, allowing only the private key holder to decrypt and access the . Integrity and are supported via digital signatures, where the sender signs the message with their private key, enabling the recipient to verify authenticity and unaltered content using the sender's public key. is also provided, as a valid signature binds the sender irrevocably to the message, preventing denial of origin. These principles rely on the computational difficulty of inverting certain mathematical functions without the private key, often referred to as one-way functions. Developed in the to address the challenges inherent in symmetric systems—where securely sharing a single key over insecure channels is problematic—public-key cryptography revolutionized by enabling via public directories. In a basic workflow, the sender obtains the recipient's public key, encrypts the plaintext message to produce ciphertext, and transmits it over an open channel; the recipient then applies their private key to decrypt the message, ensuring only they can recover the original content. This approach underpins modern secure protocols without requiring trusted intermediaries for initial key setup.

Key Components

Public and private keys form the core of public-key cryptography, generated as a mathematically related pair through specialized algorithms. The public key is designed for open distribution to enable secure communications with multiple parties, while the private key must be kept confidential by its owner to maintain system security. This asymmetry allows anyone to encrypt messages or verify signatures using the public key, but only the private key holder can decrypt or produce valid signatures. Certificates play a crucial role in associating public keys with specific identities, preventing impersonation and enabling trust in distributed systems. Issued by trusted certificate authorities (CAs), a contains the public key, the holder's identity details, and a from the CA verifying the binding. This structure, as defined in standards like , allows verification of key authenticity without direct knowledge of the private key. Key rings provide a practical mechanism for managing multiple keys, particularly in decentralized environments. In systems like Pretty Good Privacy (PGP), a public key ring stores the public keys of other users for and verification, while a separate private key ring holds the user's own private keys, protected by passphrases. These structures facilitate efficient key lookup and usage without compromising secrecy. Different public-key algorithms exhibit varying properties in terms of , computational demands, and achievable levels, influencing their suitability for applications. The table below compares representative algorithms for equivalent security strength, based on NIST guidelines for key lengths providing at least 128 bits of security against classical attacks. Computational costs are relative, with (ECC) generally requiring fewer resources due to smaller keys and optimized operations compared to RSA or DSA.
AlgorithmKey Size (bits)Relative Computation CostSecurity Level (bits)
RSA3072High (modular exponentiation intensive)128
ECC256Low (efficient scalar multiplication)128
DSA3072 (modulus)Medium (discrete log operations)128
Usability of public-key systems hinges on secure during key creation, as predictable can undermine the mathematical hardness assumptions underlying key pair security. Deterministic or weakly random sources risk exposing private keys through bias or predictability, necessitating cryptographically secure pseudorandom number generators compliant with standards like those in NIST SP 800-90.

Mathematical Foundations

Asymmetric Encryption Basics

Asymmetric encryption, a cornerstone of public-key cryptography, employs a pair of mathematically related keys: a publicly available key that anyone can use to encipher a , and a secret private key held only by the intended recipient for decryption. This approach allows over insecure channels without the need for prior secret , fundamentally differing from symmetric methods by decoupling encryption and decryption processes. The underlying mathematics is rooted in , where computations are confined to residues modulo a large composite nn, enabling efficient operations while obscuring the original without the private key. At the heart of asymmetric encryption lie one-way functions, which are algorithms or mathematical operations that are straightforward and efficient to compute in the forward direction—for instance, transforming an input xx to an output y=f(x)y = f(x)—but computationally infeasible to reverse, meaning finding xx given yy requires prohibitive resources unless augmented by a hidden "" parameter known only to the key holder. These functions provide the : the public key enables easy forward computation for , while inversion demands the private key's trapdoor information, rendering decryption secure against adversaries. A basic representation of the encryption process uses : the cc is generated as c≡me(modn)c \equiv m^e \pmod{n}, where mm is the message, ee is the public exponent component of the key, and nn is the modulus. Decryption reverses this via the private exponent dd, yielding m≡cd(modn)m \equiv c^d \pmod{n}, with the relationship between ee and dd tied to the structure of nn. The of asymmetric schemes relies on well-established computational hardness assumptions, such as the problem, where decomposing a large composite n=p⋅qn = p \cdot q (with pp and qq being large primes) into its prime factors is believed to be intractable for sufficiently large values using current algorithms and computing power.

Trapdoor One-Way Functions

Trapdoor one-way functions form the foundational mathematical primitive enabling public-key cryptography by providing a mechanism for reversible computation that is computationally feasible only with privileged information. Introduced by Diffie and Hellman, these functions are defined such that forward computation is efficient for anyone, but inversion—recovering the input from the output—is computationally intractable without a secret "" parameter, which serves as the private key. With the trapdoor, inversion becomes efficient, allowing authorized parties to decrypt or verify messages while maintaining security against adversaries. This asymmetry underpins the feasibility of public-key systems, where the public key enables easy forward evaluation, but the private key () is required for reversal. Trapdoor functions are typically categorized into permutation-based and function-based types, depending on whether they preserve one-to-one mappings. Permutation-based trapdoor functions, such as those underlying the RSA cryptosystem, involve bijective mappings that are easy to compute forward but hard to invert without knowledge of the trapdoor, often relying on the difficulty of factoring large composite numbers. For instance, in RSA, the public operation raises a message to a power modulo a composite modulus n=pqn = pq, while inversion uses the private exponent derived from the prime factors pp and qq. In contrast, function-based examples like the Rabin cryptosystem employ quadratic residues modulo nn, where forward computation squares the input modulo nn, and inversion requires extracting square roots, which is feasible only with the factorization of nn. These examples illustrate how trapdoor functions can be constructed from number-theoretic problems, ensuring that the public key reveals no information about the inversion process. The inversion process in trapdoor functions can be formally expressed as recovering the original message mm from the ciphertext cc using the private key: m = \text{private_key}(c) This operation leverages the secret trapdoor, such as the prime factors in RSA or Rabin, to efficiently compute the inverse without solving the underlying hard problem directly. The security of trapdoor one-way functions is established through provable reductions to well-studied hard problems in computational number theory, ensuring that breaking the function is at least as difficult as solving these problems. For permutation-based schemes like RSA and Rabin, security reduces to the integer factorization problem: an adversary who can invert the function efficiently could factor the modulus nn, a task believed to be intractable for large semiprimes on classical computers. Similarly, other trapdoor constructions, such as those based on the discrete logarithm problem in elliptic curves or finite fields, reduce inversion to computing discrete logarithms, providing rigorous guarantees that the system's hardness inherits from these foundational assumptions. This reductionist approach allows cryptographers to analyze and trust public-key schemes by linking their security to long-standing open problems.

Core Operations

Key Generation and Distribution

In public-key cryptography, key generation produces a mathematically linked pair consisting of a public key, which can be freely shared, and a private key, which must remain secret. Methods vary by algorithm; for systems like RSA based on , this generally involves selecting large, randomly chosen prime numbers as foundational parameters, computing a modulus from their product, and deriving public and private exponents that enable asymmetric operations based on the underlying trapdoor one-way function. In general, the process uses high-entropy random bits from approved sources to select parameters suited to the computational hard problem of the algorithm (e.g., elliptic curve parameters for ECC), and must occur within a secure environment, often using approved cryptographic modules to ensure the keys meet the required security strength. High is essential during to produce unpredictable values, preventing attackers from guessing or brute-forcing the private key from the one. Random bit strings are sourced from approved random bit generators (RBGs), such as those compliant with NIST standards, which must provide at least as many bits of as the target level—for instance, at least 256 bits for 128-bit . Insufficient , often from flawed or predictable sources like low-variability timers, can render keys vulnerable; a notable example is the 2006-2008 vulnerability (CVE-2008-0166), where a change reduced the random pool to a single PID value, generating only about 15,000 possible SSH keys and enabling widespread compromises. Secure distribution focuses on disseminating the public key while protecting the private key's secrecy. Methods include direct exchange through trusted channels like in-person handoff or , publication in public directories or key servers for open retrieval, or establishment via an initial to bootstrap trust. To mitigate risks like man-in-the-middle attacks, public keys are often accompanied by digital signatures for validation, confirming their authenticity without delving into signature mechanics. Private keys are never distributed and must be generated and stored with protections against extraction, such as hardware security modules. Common pitfalls in distribution, such as unverified public keys, can undermine the system, emphasizing the need for integrity checks during sharing.

Encryption and Decryption Processes

In public-key cryptography, the encryption process begins with preparing the plaintext message for secure transmission using methods specific to the algorithm. The message is first converted into a numerical representation and padded using a scheme such as (OAEP) to achieve a length compatible with the , prevent attacks like chosen-ciphertext vulnerabilities, and randomize the input for . In the RSA algorithm, for example, the padded message mm, treated as an integer less than the modulus nn, is then encrypted by raising it to the power of the public exponent ee modulo nn, yielding the ciphertext c=memod  nc = m^e \mod n. Other schemes, such as ElGamal, employ different operations based on discrete logarithms. This operation ensures that only the corresponding private key can efficiently reverse it, leveraging the trapdoor property of the underlying . Decryption reverses this process using the private key. In RSA, the recipient applies the private exponent dd to the , computing m=cdmod  nm = c^d \mod n, which recovers the padded . The padding is then removed, with built-in checks—such as hash verification in OAEP—to detect and handle errors like invalid padding or tampering, rejecting the decryption if inconsistencies arise. This step ensures the original is accurately restored only by the legitimate holder of the private key, maintaining . Public-key encryption typically processes messages in fixed-size blocks limited by algorithm parameters, such as the modulus nn in RSA (typically 2048 to 4096 bits as of 2025), unlike many symmetric stream ciphers that handle arbitrary lengths continuously. This imposes a per-block size restriction, often requiring messages to be segmented or, for larger data, combined with symmetric methods in hybrid systems to encrypt bulk content efficiently. Performance-wise, public-key operations incur significant computational overhead due to large-integer arithmetic, which scales cubically with the parameter size and requires far more resources—often thousands of times slower—than symmetric counterparts for equivalent levels. For instance, encrypting a 200-digit block with RSA on general-purpose hardware in the took seconds to minutes, highlighting the need for optimization techniques like . This overhead limits direct use for high-volume data, favoring hybrid approaches where public-key methods secure symmetric keys.

Digital Signature Mechanisms

Digital signature mechanisms in public-key cryptography provide a means to verify the authenticity and integrity of a message, ensuring that it originated from a specific signer and has not been altered. Introduced conceptually by Diffie and Hellman in , these mechanisms rely on asymmetric key pairs where the private key is used for signing and the public key for verification, leveraging the computational infeasibility of deriving the private key from the public one. This approach allows anyone to verify the signature without needing to share secret keys securely. To create a digital signature, the signer first applies a collision-resistant hash function to the message, producing a fixed-size digest that represents the message's content. The signer then applies their private key to this digest, effectively "encrypting" it to generate the signature. For instance, in the RSA algorithm proposed by Rivest, Shamir, and Adleman in 1978, the signature SS is computed as S=hdmod  nS = h^d \mod n, where hh is the hash of the message, dd is the private exponent, and nn is the modulus derived from the product of two large primes. This process ensures that only the holder of the private key can produce a valid signature, as the operation exploits the trapdoor one-way function inherent in the public-key system. For longer messages, hashing is essential to reduce the input to a manageable size, preventing the need to sign each block individually while maintaining security. Other schemes, such as DSA or ECDSA, use different signing operations based on their mathematical foundations. Verification involves the recipient recomputing the hash of the received message and using the signer's key to "decrypt" the , yielding the original digest. The verifier then compares this decrypted value with the newly computed hash; if they match, the is valid, confirming both the message's and the signer's identity. In RSA terms, this check is performed by computing h′=Semod  nh' = S^e \mod n, where ee is the exponent, and ensuring h′h' equals the hash of the message. The use of strong hash functions is critical here, as their property makes it computationally infeasible for an attacker to find two different messages with the same hash, thereby preventing of signatures on altered content. A key property of digital signatures is , which binds the signer irrevocably to the message since only their private key could have produced the valid , and the public key allows third-party verification without the signer's involvement. This feature underpins applications such as secure protocols and , where verifiable authenticity is paramount.

Applications and Schemes

Secure Data Transmission

Public-key cryptography plays a pivotal role in secure data transmission by enabling the establishment of encrypted channels over open networks without requiring pre-shared secrets between parties. This addresses the problem inherent in symmetric cryptography, allowing communicators to securely exchange information even in untrusted environments like the internet. By leveraging asymmetric key pairs, it ensures , as data encrypted with a public key can only be decrypted by the corresponding private key held by the intended recipient. In protocols such as (TLS), public-key cryptography facilitates during the initial handshake to derive symmetric session keys for bulk data encryption. For instance, TLS 1.3 mandates the use of ephemeral Diffie-Hellman (DHE) or Diffie-Hellman (ECDHE) key exchanges, where parties generate temporary public values to compute a , providing to protect past sessions against future key compromises. This mechanism authenticates the exchange via digital signatures and encrypts subsequent handshake messages, ensuring secure transmission of application data thereafter. For email encryption, standards like OpenPGP and rely on public-key cryptography to protect message confidentiality. OpenPGP employs a hybrid approach where a randomly generated symmetric encrypts the email content, and that session key is then encrypted using the recipient's public key (e.g., via RSA or ElGamal) before transmission. Similarly, uses the (CMS) to wrap a content-encryption key with the recipient's public key through algorithms like RSA or ECDH, supporting enveloped data structures for secure delivery. In file sharing scenarios, public-key cryptography enables secure uploads and downloads by allowing senders to encrypt files with the recipient's public key prior to transmission, preventing interception on public networks. OpenPGP implements this by applying the same hybrid encryption process to files as to messages, where symmetric encryption handles the data and public-key encryption secures the , ensuring end-to-end without shared infrastructure. This approach integrates with symmetric methods for performance, as explored in hybrid systems.

Authentication and Non-Repudiation

Public-key cryptography enables by allowing parties to verify the identity of a communicator through the use of digital signatures, which demonstrate possession of a corresponding private key without revealing it. In this context, confirms that the entity claiming an identity is genuine, while ensures that a signer cannot later deny having performed a signing operation, providing evidentiary value in disputes. These properties rely on the asymmetry of key pairs, where the private key signs data and the public key verifies it, binding actions to specific identities. Challenge-response authentication protocols leverage digital signatures to prove private key possession securely. In such protocols, a verifier sends a random challenge—a nonce or timestamped value—to the claimant, who then signs it using their private key and returns the signature along with the challenge. The verifier checks the signature against the claimant's public key; successful verification confirms the claimant controls the private key, as forging the signature would require solving the underlying hard problem, such as in RSA. This method resists replay attacks when fresh challenges are used and is specified in standards like FIPS 196 for entity in computer systems. Non-repudiation in public-key systems is achieved through timestamped s that bind a signer's identity to a or action, making denial infeasible due to the cryptographic uniqueness of the . A signer applies their private key to hash the and a trusted , producing a verifiable artifact that third parties can validate with the public key. This ensures the was created after the and before any , providing legal evidentiary weight, as outlined in digital standards like DSS. The RSA algorithm, introduced in 1977, formalized this capability by enabling signatures that are computationally infeasible to forge without the private key. Another prominent application is in and systems, where users generate public-private key pairs to create wallet addresses from public keys and sign transactions with private keys; verifiers use the public key to confirm authenticity and prevent unauthorized spending, ensuring across distributed networks. Certificate-based authentication extends these mechanisms by linking public keys to real-world identities via certificates issued by trusted authorities. Each certificate contains the subject's public key, identity attributes (e.g., name or ), and a from the issuing certification authority, forming a from a root authority. During authentication, the verifier validates the certificate chain, checks status via certificate lists, and uses the bound public key to confirm signatures, ensuring the key belongs to the claimed entity. This approach, profiled in RFC 5280, supports scalable identity verification in distributed systems. In software updates, public-key cryptography facilitates code signing, where developers sign binaries with their private key to assure users of authenticity and integrity, preventing tampering during distribution. For instance, operating systems like Windows verify these signatures before installation, using the associated public key or certificate to block unsigned or altered code. Similarly, in legal documents, electronic signatures employ public-key digital signatures to provide , as seen in frameworks like the U.S. ESIGN Act, which recognizes signatures verifiable via public keys as binding equivalents to handwritten ones. This ensures contracts or approvals cannot be repudiated, with timestamps adding proof of creation time.

Hybrid Systems

Combining with Symmetric Cryptography

Public-key cryptography is frequently combined with symmetric cryptography in hybrid cryptosystems to optimize security and performance. Asymmetric methods handle initial key establishment or exchange securely over public channels, deriving a shared symmetric key without prior secrets, while symmetric algorithms then encrypt and decrypt the bulk of the data due to their greater speed and efficiency for large volumes. This hybrid model addresses the computational intensity of public-key operations, which are impractical for direct of extensive payloads, and enhances overall resilience.

Protocol Examples

Key examples of hybrid systems include TLS, where public-key-based key exchanges like ECDHE derive session keys for symmetric ciphers such as AES, securing web communications. In email and file encryption via OpenPGP, a symmetric key encrypts the content, which is then wrapped with the recipient's public key for secure delivery. Similarly, uses with Diffie-Hellman to establish symmetric keys for VPN tunnels, combining authentication via digital signatures with efficient data protection.

Hybrid Systems

Combining with Symmetric Cryptography

Public-key cryptography, while enabling secure without prior shared secrets, is computationally intensive and significantly slower for encrypting large volumes of data compared to symmetric cryptography. Symmetric algorithms, such as AES, excel at efficiently processing bulk data due to their simpler operations, but they require a for to prevent interception. This disparity in performance—where public-key methods can be up to 1,000 times slower than symmetric ones for equivalent security levels—necessitates a hybrid approach to leverage the strengths of both paradigms. In hybrid systems, public-key cryptography facilitates the secure exchange of a temporary symmetric , which is then used to encrypt the actual . The standard pattern involves the sender generating a random symmetric key, applying it to encrypt the message via a symmetric algorithm, and subsequently encrypting that symmetric key using the recipient's public key before transmission. Upon receipt, the recipient decrypts the symmetric key with their private key and uses it to decrypt the message. This method ensures without the overhead of applying public-key operations to the entire data stream. The efficiency gains from this integration are substantial; for instance, hybrid encryption achieves approximately 1,000-fold speedup in bulk data processing relative to pure public-key encryption, making it practical for real-world applications like secure file transfers or streaming. Standards such as Hybrid Public Key Encryption (HPKE) incorporate ephemeral Diffie-Hellman key exchanges within public-key frameworks to encapsulate symmetric keys securely, enhancing while maintaining compatibility with symmetric ciphers. This conceptual hybrid model underpins many secure communication protocols, balancing security and performance effectively.

Protocol Examples

Public-key cryptography is integral to several widely adopted hybrid protocols, where it facilitates initial authentication and key agreement before transitioning to efficient symmetric encryption for the bulk of data transmission. These protocols leverage asymmetric mechanisms to establish trust and shared secrets securely over untrusted networks, ensuring confidentiality, integrity, and authenticity. Representative examples include the Transport Layer Security (TLS) handshake, Secure Shell (SSH), and Internet Protocol Security (IPSec) with Internet Key Exchange (IKE). In the TLS 1.3 , public-key cryptography is employed for server authentication and ephemeral key agreement. The server presents an certificate containing its public key, typically based on RSA or (ECC), which the client verifies against a trusted . The server then signs a handshake transcript using its private key (via algorithms like RSA-PSS or ECDSA) to prove possession and authenticity. Concurrently, the client and server perform an ephemeral Diffie-Hellman (DHE) or Diffie-Hellman (ECDHE) exchange using supported groups such as x25519 or secp256r1 to derive a . This secret, combined with the transcript via , generates symmetric keys for AES-GCM or of subsequent application data, embodying the hybrid model. The SSH protocol utilizes public-key cryptography primarily for host and user authentication, alongside key exchange for session establishment. During the transport layer negotiation, the server authenticates itself by signing the key exchange hash with its host private key (e.g., RSA or DSA), allowing the client to verify the signature against the server's known public key. User authentication follows via the "publickey" method, where the client proves possession of a private key by signing a challenge message, supporting algorithms like ssh-rsa or ecdsa-sha2-nistp256. Key agreement occurs through Diffie-Hellman groups (e.g., group14-sha256), producing a from which symmetric session keys are derived for ciphers like AES and integrity via , securing the remote login channel. In , public-key cryptography is optionally integrated into the IKEv2 protocol for peer and during setup. Authentication employs digital signatures in AUTH payloads, using RSA or DSS on certificates to verify peer identities, with support for formats and identifiers like FQDN or distinguished names. relies on ephemeral Diffie-Hellman (e.g., Group 14: 2048-bit modulus) to establish shared secrets with perfect , from which symmetric keys are derived via a pseudorandom function (PRF) like HMAC-SHA-256. These keys then protect IP traffic using Encapsulating Security Payload (ESP) with symmetric algorithms such as AES in GCM mode, enabling secure VPN tunnels. While pre-shared keys are common, public-key methods enhance scalability in large deployments. The following table compares these protocols in terms of public-key types and recommended levels, based on NIST guidelines for at least 112-bit strength (equivalent to breaking 2^112 operations).
ProtocolKey Types Used for Key Types Used for Recommended Levels (Key Sizes)
TLS 1.3RSA (2048 bits), ECDSA (P-256 or )ECDHE (x25519 or secp256r1, ~256 bits)128-bit (ECC) or 112-bit (RSA/DH)
SSHRSA (2048 bits), ECDSA (P-256 or ), DSADH (2048 bits, Group 14)112-bit (RSA/DH) or 128-bit (ECC)
IPSec (IKEv2)RSA (2048 bits), DSS (2048 bits)DH (2048 bits, Group 14)112-bit (RSA/DSS/DH)

Security Considerations

Algorithmic Vulnerabilities

Public-key cryptographic algorithms, while mathematically sound under their assumed hardness problems, are susceptible to vulnerabilities arising from their implementations, particularly those that leak information through non-ideal execution environments. These algorithmic weaknesses, often termed side-channel or implementation attacks, exploit physical or observational characteristics of computations rather than breaking the underlying mathematical foundations. Such vulnerabilities can compromise private keys or decrypt ciphertexts without directly solving problems like or discrete logarithms. Side-channel attacks represent a prominent class of algorithmic vulnerabilities, where attackers infer secret information from unintended information leakage during key operations. Timing attacks, first demonstrated by Paul Kocher in 1996, exploit variations in the execution time of cryptographic operations, such as in RSA or Diffie-Hellman, to recover private keys by analyzing timing differences correlated with intermediate values. For instance, in RSA implementations, the time taken for squaring and multiplication steps can reveal bits of the private exponent if not constant-time. Power analysis attacks extend this concept by measuring electrical power consumption during computations. Simple power analysis (SPA) observes direct patterns in power traces to distinguish operations like multiplications from squarings in RSA, while differential power analysis (DPA), introduced by Kocher, Jaffe, and Jun in 1999, uses statistical methods on multiple traces to isolate key-dependent signals, enabling key recovery from devices like smart cards with as few as a few hundred measurements. These attacks target public-key primitives broadly, including operations, by correlating power fluctuations with data manipulations. Fault injection attacks induce computational errors during algorithm execution to reveal private keys, exploiting the sensitivity of public-key schemes to arithmetic integrity. In 1997, Boneh, DeMillo, and Lipton demonstrated that injecting a single fault into an RSA signature computation using the (CRT) allows an attacker to factor the modulus and recover the private key, as the faulty output provides equations solvable via the . This vulnerability affects CRT-optimized RSA implementations, where a fault in one modular computation yields related faulty and correct signatures that expose the . Similar techniques apply to other schemes, such as elliptic curve digital signatures, where induced faults in point multiplications can leak scalar secrets. Countermeasures like error detection and redundancy are essential but increase computational overhead. Padding oracle attacks exploit flaws in the padding schemes used within public-key encryption protocols, allowing adaptive chosen-ciphertext decryption without the private key. In 1998, Daniel Bleichenbacher described an on RSA with PKCS#1 v1.5 , where an revealing whether a ciphertext decrypts to valid enables the attacker to iteratively refine the plaintext space, decrypting arbitrary messages with around 360,000 queries in practice. This vulnerability stems from the malleability of RSA and the 's distinction between valid and invalid paddings, affecting protocols like SSL/TLS. Similarly, Serge Vaudenay's 2002 analysis of CBC-mode in hybrid systems revealed that validation can decrypt ciphertexts block-by-block, applicable to public-key wrapped symmetric keys in standards like and WTLS, with decryption requiring roughly 128*b queries for a b-block message. These attacks highlight the need for deterministic checks without leakage, leading to the adoption of stricter schemes like OAEP and countermeasures in RFC 3447.

Key Management Challenges

One significant challenge in public-key cryptography arises from key alteration attacks, where an adversary performs a man-in-the-middle (MITM) substitution by intercepting and replacing a legitimate public key with a malicious one during distribution or exchange. This allows the attacker to decrypt intercepted communications or forge signatures while remaining undetected, as the victim and intended recipient continue using the substituted key. To mitigate such attacks, public keys are typically distributed via trusted channels or certified through (PKI) mechanisms that bind keys to verified identities. Another critical issue involves key revocation and expiration, as public keys must be invalidated when compromised, superseded, or reaching the end of their cryptoperiod to prevent misuse. Mechanisms like Certificate Revocation Lists (CRLs), standardized in the framework, provide a signed list issued by a certification authority (CA) containing serial numbers of revoked certificates, along with revocation dates and reasons such as key compromise. Relying parties query CRLs periodically or use extensions like delta CRLs for incremental updates to check certificate status during validation, ensuring that expired or invalid keys are not trusted. (OCSP) serves as an alternative for real-time queries, though CRLs remain foundational for batch revocation in large-scale PKI deployments. Secure storage of private keys poses substantial risks, as exposure to theft or unauthorized access can compromise entire cryptographic systems. Hardware Security Modules (HSMs), validated under standards like , are widely recommended to protect private keys by performing cryptographic operations within tamper-resistant hardware, preventing key export and limiting access to authorized processes. These modules ensure confidentiality and integrity through physical and logical controls, such as split knowledge procedures where no single entity holds full access, thereby reducing insider threats and side-channel attacks. Backup and recovery processes introduce further challenges, as private keys must be securely archived for disaster recovery without enabling unauthorized restoration. Key recovery systems (KRS) often involve escrowing portions of keys with trusted third parties or using encrypted backups stored in separate, physically secure locations, with recovery requiring multi-party approval to maintain . NIST guidelines emphasize that backups should use approved key-wrapping techniques and be protected equivalently to operational keys, while destruction of unnecessary copies prevents accumulation of vulnerabilities over time. PKI frameworks briefly support such recovery through CA-managed policies.

Infrastructure and Metadata Risks

Public Key Infrastructure (PKI) forms the foundational framework for managing public keys and certificates in asymmetric cryptography systems, enabling secure verification of identities and trust establishment across networks. Central to PKI are Certificate Authorities (CAs), which are trusted entities responsible for issuing, signing, and managing digital certificates that bind public keys to specific identities or entities. Registration Authorities (RAs) complement CAs by performing identity verification and authentication tasks on behalf of the CA before certificate issuance, ensuring that only legitimate requests are processed. Trust chains, or certification paths, link end-entity certificates back to a trusted root CA through a series of intermediate certificates, allowing relying parties to validate authenticity via transitive trust. A primary infrastructure risk in PKI arises from CA compromise, where attackers gain unauthorized access to a CA's private keys or systems, enabling the issuance of fraudulent certificates that can impersonate legitimate entities. The 2011 DigiNotar breach exemplifies this vulnerability: hackers infiltrated the Dutch CA's network in June 2011, compromising its systems and issuing over 500 rogue certificates for high-profile domains like google.com, which were used in man-in-the-middle attacks targeting Iranian users. This incident eroded global trust in the affected CA, leading to its revocation from major browser trust stores and eventual bankruptcy in September 2011, while prompting widespread reforms in CA auditing and liability standards. Certificate mis-issuance represents another systemic threat, occurring when CAs erroneously validate and issue certificates to unauthorized parties due to flawed vetting processes or insider errors, potentially enabling phishing sites or unauthorized access. Studies of web PKI certificates have identified mis-issuance rates through tools like ZLint, revealing persistent errors in validation that undermine the entire trust model. Beyond core infrastructure, metadata risks in public-key cryptography persist even when payloads are encrypted, as ancillary data such as protocol headers, timestamps, and certificate details can leak sensitive patterns about communication endpoints, volumes, or timings. For instance, in protocols like TLS, unencrypted headers may expose server names or negotiation parameters, while embedded timestamps in certificates can reveal issuance patterns indicative of user behavior. Such leaks facilitate attacks, where adversaries infer relationships or routines without decrypting content, as demonstrated in schemes where servers manipulate timings to expose communication graphs. To mitigate these infrastructure risks, CAs employ Modules (HSMs), tamper-resistant devices that securely generate, store, and use private keys, preventing extraction even under physical attack and ensuring compliance with standards like FIPS 140-3. For metadata exposure, emerging protocols incorporate for headers and auxiliary fields, such as in forward-edge proxy designs that obfuscate version, length, and protocol to hinder detection and analysis. These measures, including multi-server chaining with mathematical guarantees against pattern revelation, enhance privacy without compromising core cryptographic functions.

Historical Development

Pre-1970s Concepts

In the early , described a biliteral in his work De Augmentis Scientiarum, a steganographic system that encoded messages using two distinct forms of letters (e.g., variations in typefaces or shapes) embedded within an innocuous carrier text. This method allowed for the concealment of information without altering the apparent meaning of the document, representing an early exploration of communication where the encoding mechanism could be somewhat decoupled from the shared understanding of the content, though it relied on the recipient knowing the two alphabets to decode. During the 1940s and 1950s, applied to in his seminal 1949 paper "Communication Theory of Secrecy Systems," formalizing the requirements for secure communication. Shannon proved that achieving perfect secrecy necessitates a secret key at least as long as the , randomly generated, and used only once (as in the ), but he underscored the practical challenge of securely distributing such keys between parties over insecure channels without prior shared secrets—a limitation that became known as the problem. This analysis highlighted the theoretical need for alternative approaches to key establishment, setting the stage for later innovations in asymmetric systems. In 1970, British cryptographer James H. Ellis at proposed the concept of "non-secret encryption" in an internal existence proof, demonstrating theoretically that encryption could be performed using a public algorithm where the sender and receiver share only a secret key for decryption, without the need for secure beforehand. Ellis's work outlined a lookup-table model for such a system but lacked a practical implementation, remaining classified until the ; it anticipated the core idea of public-key cryptography by separating the roles of encryption and decryption keys.

Classified and Public Innovations

In the early 1970s, researchers at the UK's Government Communications Headquarters (GCHQ), specifically within its Communications-Electronics Security Group (CESG), developed the foundational concepts of public-key cryptography in a classified environment. James H. Ellis initiated this work in 1969 by exploring solutions to key distribution problems, leading to a theoretical demonstration of the feasibility of non-secret encryption—a system where the encryption key could be publicly shared without compromising security. In January 1970, Ellis formalized this idea in an internal report titled "The Possibility of Secure Non-Secret Digital Encryption," providing an existence proof but lacking a practical implementation due to computational limitations at the time. Building on Ellis's vision, Clifford C. Cocks, a mathematician who joined in 1973, devised a practical scheme in November of that year, using properties of large prime numbers and to enable asymmetric similar to later public algorithms. Independently addressing the challenge, Malcolm J. Williamson, who joined in 1974, developed a method in January 1974 for two parties to agree on a over an insecure channel, akin to discrete logarithm-based key agreement systems. These innovations, kept secret for reasons, established the core principles of public-key cryptography by 1975, though they remained internal to and were not deployed operationally due to hardware constraints. The public emergence of public-key cryptography occurred in the mid-1970s through unclassified academic work in the United States. In November 1976, Whitfield Diffie and Martin E. Hellman published "New Directions in Cryptography" in IEEE Transactions on Information Theory, introducing a key agreement protocol that allowed secure key exchange without prior shared secrets, relying on the computational difficulty of the discrete logarithm problem. This paper laid the groundwork for public-key systems by emphasizing one-way functions and public directories for key distribution. Following closely, in February 1978 (submitted April 1977), Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman described the RSA cryptosystem in Communications of the ACM, proposing an encryption method based on the hardness of integer factorization, which supported both confidentiality and digital signatures. The contributions remained classified until December 1997, when the UK government declassified key documents and publicly announced their prior inventions at a in , England, acknowledging the independent public discoveries while revealing the earlier classified timeline. This disclosure highlighted that 's work predated the public papers by several years but had no immediate impact on due to secrecy. On the commercialization front, Rivest, Shamir, and Adleman filed a U.S. for the RSA on December 14, 1977 (U.S. , granted September 20, 1983), marking the first for a public-key system. To exploit this invention, they founded RSA Data Security Inc. in 1982, which licensed the technology to software vendors and integrated RSA into products like secure and network protocols, driving its adoption in commercial applications despite ongoing enforcement until expiration in 2000.

Specific Algorithms

RSA and Integer Factorization

The RSA algorithm, named after its inventors , , and , is a foundational public-key introduced in that enables secure data transmission without prior exchange of secret keys. It operates on the principle of asymmetric encryption, where a public key encrypts messages and a corresponding private key decrypts them, making it suitable for applications like secure and digital signatures. The algorithm's design leverages basic number theory to ensure that deriving the private key from the public key is computationally infeasible for large parameters. Key generation in RSA begins with selecting two large, distinct prime numbers, denoted as pp and qq, typically of similar bit length to balance security and efficiency. The modulus nn is then computed as the product n=p×qn = p \times q, which forms the core of both the public and private keys. The totient ϕ(n)=(p−1)(q−1)\phi(n) = (p-1)(q-1) is calculated next, followed by choosing a public exponent ee such that 1<e<ϕ(n)1 < e < \phi(n) and gcd⁡(e,ϕ(n))=1\gcd(e, \phi(n)) = 1, often using small values like 65537 for performance. The private exponent dd is derived as the modular multiplicative inverse of ee modulo ϕ(n)\phi(n), satisfying d×e≡1(modϕ(n))d \times e \equiv 1 \pmod{\phi(n)}. The public key consists of (n,e)(n, e), while the private key is (n,d)(n, d), with pp and qq kept secret to prevent reconstruction of ϕ(n)\phi(n). Encryption transforms a plaintext message mm (where 0≤m<n0 \leq m < n) into ciphertext cc using the public key via the formula: c=memod  nc = m^e \mod n Decryption reverses this process with the private key: m=cdmod  nm = c^d \mod n This works because of Euler's theorem, which guarantees that mkϕ(n)+1≡m(modn)m^{k \phi(n) + 1} \equiv m \pmod{n} for gcd⁡(m,n)=1\gcd(m, n) = 1, and since d≡e−1(modϕ(n))d \equiv e^{-1} \pmod{\phi(n)}, it follows that cd≡m(modn)c^d \equiv m \pmod{n}; the relation holds even if gcd⁡(m,n)≠1\gcd(m, n) \neq 1 due to the Chinese Remainder Theorem applied to pp and qq. In practice, messages longer than nn are segmented or hybridized with symmetric ciphers, but raw RSA without padding is deterministic and vulnerable to certain attacks, necessitating probabilistic enhancements. The security of RSA fundamentally relies on the computational hardness of integer factorization: given nn, it is easy to compute but extremely difficult to recover pp and qq without exhaustive search or advanced algorithms like the General Number Field Sieve, especially for large nn. Factoring nn allows computation of ϕ(n)\phi(n) and thus dd, compromising the system; no efficient classical algorithm exists for factoring semiprimes of sufficient size, providing the assumed one-way trapdoor function. However, security also depends on proper implementation, as side-channel attacks or poor randomness in key generation can weaken it independently of factorization difficulty. To mitigate vulnerabilities in raw RSA, such as chosen-ciphertext attacks, padding schemes are essential. The Optimal Asymmetric Encryption Padding (OAEP) scheme, standardized in PKCS#1, incorporates a feistel-like structure with a hash function (e.g., SHA-256) and mask generation function to add randomness and diffusion to the plaintext before exponentiation, ensuring semantic security under the RSA assumption. OAEP transforms the message into a padded block that includes seed bytes, making identical plaintexts yield different ciphertexts and resisting adaptive attacks. For key sizes, NIST recommends at least 2048 bits for RSA moduli to achieve 112 bits of security through 2030, with 3072 bits for longer-term protection against foreseeable advances in factoring; smaller keys like 1024 bits are deprecated due to demonstrated factorizations. Implementations must generate primes using probabilistic tests (e.g., Miller-Rabin) to ensure their secrecy and uniformity.

Elliptic Curve Cryptography

Elliptic curve cryptography (ECC) is a public-key cryptosystem that leverages the algebraic structure of elliptic curves over finite fields to provide security based on the difficulty of the elliptic curve discrete logarithm problem (ECDLP). Proposed independently by Neal Koblitz and Victor S. Miller in the mid-1980s, ECC enables efficient implementations of key agreement, encryption, and digital signatures with smaller key sizes compared to other systems offering equivalent security levels. The core operations rely on the group structure of points on the curve, where scalar multiplication serves as the foundational hard problem. An elliptic curve over a prime finite field Fp\mathbb{F}_p (with p>3p > 3) is typically defined by the Weierstrass equation y2=x3+ax+b(modp),y^2 = x^3 + ax + b \pmod{p}, where a,b∈Fpa, b \in \mathbb{F}_p satisfy the non-singularity condition 4a3+27b2≢0(modp)4a^3 + 27b^2 \not\equiv 0 \pmod{p} to ensure the curve is smooth. The set of points (x,y)(x, y) satisfying this equation, augmented by a O\mathcal{O} serving as the identity, forms an under a geometrically defined operation. Point addition combines two points to yield a third on the curve: for distinct points P=(x1,y1)P = (x_1, y_1) and Q=(x2,y2)Q = (x_2, y_2), the slope λ=(y2−y1)(x2−x1)−1(modp)\lambda = (y_2 - y_1)(x_2 - x_1)^{-1} \pmod{p}, and the sum R=P+Q=(x3,y3)R = P + Q = (x_3, y_3) where x3=λ2−x1−x2(modp),y3=λ(x1−x3)−y1(modp).x_3 = \lambda^2 - x_1 - x_2 \pmod{p}, \quad y_3 = \lambda(x_1 - x_3) - y_1 \pmod{p}. Point doubling for P=(x1,y1)P = (x_1, y_1) uses λ=(3x12+a)(2y1)−1(modp)\lambda = (3x_1^2 + a)(2y_1)^{-1} \pmod{p}, with the same formulas for R=2PR = 2P. These operations are efficient and enable repeated to compute scalar multiples kPkP for integer kk. Key generation in ECC involves selecting a standardized curve with a large prime order subgroup generated by a base point GG, where the subgroup order nn is approximately the size of the field (e.g., n≈pn \approx p). The private key is a scalar k∈{1,2,…,n−1}k \in \{1, 2, \dots, n-1\}, and the corresponding public key is the point Q=kGQ = kG, computed via scalar multiplication. Security rests on the ECDLP: given GG and QQ, computing kk is computationally infeasible for properly chosen curves, as no subexponential algorithms are known, unlike some discrete logarithm variants in finite fields. The Diffie-Hellman (ECDH) protocol adapts key agreement to this setting: party A selects private key aa and computes A=aGA = aG, while party B uses bb and B=bGB = bG; the is then abGabG, derived as aB=bAaB = bA. This is standardized in NIST SP 800-56A for pairwise key establishment using elliptic curves. For digital signatures, the (ECDSA) generates a pair (r,s)(r, s) where rr is the x-coordinate (mod nn) of kGkG for random kk, and s=k−1(e+rd)(modn)s = k^{-1}(e + rd) \pmod{n} with private key dd and message hash ee; verification checks if s−1eG+s−1rQ=(r,⋅)s^{-1}e G + s^{-1}r Q = (r, \cdot). ECDSA is specified in FIPS 186-5 as an approved method for federal systems. A primary advantage of ECC is its efficiency: it achieves comparable strengths to RSA with significantly smaller keys and faster computations, reducing bandwidth, storage, and demands—particularly beneficial for resource-constrained devices. For instance, a 256-bit ECC key provides approximately 128 bits of , equivalent to a 3072-bit RSA key, while a 384-bit ECC key matches 192-bit against a 7680-bit RSA key. These levels are recommended by NIST for protecting sensitive data through at least 2030 (128-bit) or longer.

Discrete Logarithm-Based Systems

Discrete logarithm-based systems rely on the computational hardness of the problem (DLP) in finite fields, particularly in the of integers modulo a large prime pp. The DLP is defined as follows: given a prime pp, a generator gg of the Zp×\mathbb{Z}_p^\times, and an element y∈Zp×y \in \mathbb{Z}_p^\times, find the integer xx such that gx≡y(modp)g^x \equiv y \pmod{p}, where 0≤x<p−10 \leq x < p-1. This problem is believed to be intractable for sufficiently large pp (typically thousands of bits), as no efficient algorithm is known to solve it in general, distinguishing it from easier problems like . The Diffie-Hellman (DH) key exchange, introduced in 1976, was the first practical application of the DLP in public-key cryptography and enables two parties to establish a over an insecure channel without prior secrets. In the protocol, both parties agree on public parameters pp and gg; Alice selects a private exponent aa and sends ga(modp)g^a \pmod{p} to Bob, who selects bb and sends gb(modp)g^b \pmod{p}. The is then gab(modp)g^{ab} \pmod{p}, computable by Alice as (gb)a(modp)(g^b)^a \pmod{p} and by Bob as (ga)b(modp)(g^a)^b \pmod{p}. Security relies on the difficulty of the computational Diffie-Hellman problem, a variant of the DLP, preventing an eavesdropper from deriving the secret from the public exchanges. ElGamal encryption, proposed by Taher ElGamal in 1985, extends the DH mechanism to provide asymmetric encryption based on the DLP. The public key consists of pp, gg, and y=gx(modp)y = g^x \pmod{p} where xx is the private key. To encrypt a message mm (with 0<m<p0 < m < p), the sender chooses a random kk and computes the ciphertext as a pair (c1,c2)(c_1, c_2), where c1=gk(modp)c_1 = g^k \pmod{p} and c2=m⋅yk(modp)c_2 = m \cdot y^k \pmod{p}. Decryption recovers m=c2⋅(c1x)−1(modp)m = c_2 \cdot (c_1^x)^{-1} \pmod{p}, leveraging the private key xx. This scheme is probabilistically secure under the decisional Diffie-Hellman assumption but requires careful padding for in practice. Variants of DL-based systems include the (DSA), standardized by NIST in the Digital Signature Standard (DSS), which adapts ElGamal principles for digital signatures. In DSA, a signer uses private key xx to produce a signature (r,s)(r, s) on a message hash, verifiable with the public key y=gx(modp)y = g^x \pmod{p}; it provides under the DLP's hardness. Parameter selection is critical for : NIST recommends domain parameters with a modulus pp of at least 2048 bits (providing approximately 112 bits of ) for both DH and DSA, with subgroup order qq of 256 bits, and larger sizes like 3072 bits for extended protection against advances in algorithms such as the number field sieve.

Modern and Future Directions

Post-Quantum Cryptography

Public-key cryptography faces existential threats from , particularly through , which was introduced by in 1994 and enables efficient and computation on a sufficiently large quantum computer. This quantum algorithm would render widely used systems like RSA, (ECC), and discrete logarithm-based protocols insecure by solving their underlying hard problems in polynomial time, potentially allowing decryption of encrypted data harvested today for future quantum attacks. As quantum computers advance toward practical scalability, the need for quantum-resistant alternatives has driven the development of (), which relies on mathematical problems believed to be resistant to both classical and quantum attacks. PQC algorithms are categorized into several families, including lattice-based, hash-based, and code-based schemes, each offering key encapsulation or digital signatures with varying trade-offs in security and efficiency. Lattice-based candidates, such as CRYSTALS-Kyber, leverage the hardness of problems like (LWE) and have emerged as frontrunners due to their versatility in and signatures. Hash-based signatures like SPHINCS+ provide provable security based on the collision resistance of hash functions, making them suitable for long-term digital signatures without relying on unproven number-theoretic assumptions. Code-based systems, exemplified by variants and the selected HQC, base their security on the difficulty of decoding random linear error-correcting codes, offering robust options with decades of cryptographic scrutiny. The U.S. National Institute of Standards and Technology (NIST) has led the global standardization effort for PQC since , conducting multiple rounds of public evaluation to select algorithms resistant to quantum threats. In 2022, NIST advanced CRYSTALS-Kyber, CRYSTALS-Dilithium, , and SPHINCS+ to the final round, culminating in the publication of (FIPS) 203 (ML-KEM from ), FIPS 204 (ML-DSA from ), and FIPS 205 (SLH-DSA from SPHINCS+) on August 13, 2024. In March 2024, NIST selected the code-based HQC algorithm as a backup key-encapsulation mechanism to diversify options beyond lattice-based schemes, with a draft standard expected by 2026. NIST continues evaluation of additional algorithms like for digital signatures, with standards anticipated in 2025. These selections prioritize algorithms with strong margins, efficient implementations, and minimal side-channel vulnerabilities, as verified through extensive . Transitioning to PQC introduces significant challenges, including substantially larger key and ciphertext sizes compared to classical systems—for instance, Kyber-512 public keys are about 800 bytes versus 65 bytes uncompressed for NIST P-256 ECC—leading to increased storage, bandwidth, and latency in protocols like TLS. Performance impacts are notable, with PQC signatures and encapsulations often requiring 10-100 times more computational resources than ECC equivalents, straining resource-constrained devices such as IoT endpoints and necessitating hybrid approaches during migration. Organizations must address interoperability with legacy systems, update cryptographic libraries, and conduct risk assessments to mitigate "" threats, with NIST recommending phased crypto-agility strategies to facilitate this shift.

Standardization and Emerging Threats

The Internet Engineering Task Force (IETF) has advanced standardization efforts for integrating post-quantum cryptography (PQC) into existing protocols, particularly through hybrid approaches that maintain compatibility with classical systems. RFC 9180, published in May 2022, defines a hybrid public key encryption (HPKE) scheme that combines key encapsulation mechanisms (KEMs) with key derivation functions and authenticated encryption, enabling the use of both classical and quantum-resistant algorithms to encrypt arbitrary-sized plaintexts. This standard supports post-quantum security by allowing hybrid modes, such as those incorporating pre-shared keys or authentication, to enhance resilience against quantum threats when paired with non-quantum-resistant KEMs. Following TLS 1.3's ratification in 2018, post-2020 updates have emphasized its role as the baseline for PQC integration, with the IETF draft on hybrid key exchange in TLS 1.3—last updated in November 2025 and now in the RFC Editor's Queue—specifying methods to concatenate public keys and shared secrets from multiple algorithms without adding round trips, ensuring security if at least one component remains unbroken. Emerging threats to public-key cryptography extend beyond quantum risks, including AI-assisted that leverages to identify patterns in encrypted data or optimize attacks on underlying mathematical problems. Systematic reviews highlight AI's potential to accelerate differential or infer keys from side-channel data, posing risks to systems like RSA and by exploiting computational inefficiencies in traditional defenses. Additionally, supply-chain compromises targeting cryptographic keys have surged, with attackers exploiting vulnerabilities in software dependencies or hardware to extract private keys, as seen in incidents involving code-signing abuse where stolen keys enable distribution under trusted identities. These attacks often involve side-channel techniques, such as on devices, to reveal sensitive cryptographic outputs during manufacturing or distribution. As of November 2025, the European Union's Quantum Flagship initiative remains active in its second phase under , with a exceeding €400 million over 20 new projects focused on quantum communication, computing, and sensing. Globally, migration timelines to PQC vary by region but emphasize phased transitions: the National Cyber Security Centre (NCSC) recommends completing discovery of crypto assets by 2028 and high-priority migrations by 2031, with initial validations for PQC modules expected in 2025; Canada's Cyber Centre outlines a roadmap for non-classified systems starting inventory in 2025 and full implementation by 2035; and the Post-Quantum Cryptography Coalition's roadmap urges organizations to align preparation with threat models, projecting widespread adoption by 2030 to protect long-lived data. Hybrid PQC designs address transition challenges by combining classical algorithms, such as those based on discrete logarithms, with post-quantum primitives like lattice-based schemes to ensure and during migration. Standardized terminology for these post-quantum/traditional (PQ/T) hybrid schemes defines them as multi-algorithm constructions for key establishment or signatures that require security from at least one component against both classical and quantum adversaries. For instance, protocols like TLS 1.3 can incorporate PQ/T hybrids through composite key exchanges, allowing legacy systems to interoperate while providing against quantum attacks, as outlined in NCSC guidance for minimal disruption in enterprise environments. This approach mitigates risks from incomplete migrations by preserving and confidentiality properties in mixed deployments.

References

  1. https://ee.stanford.edu/~hellman/publications/24.pdf
  2. https://csrc.nist.gov/glossary/term/public_key_cryptography
  3. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf
  4. https://people.csail.mit.edu/rivest/Rsapaper.pdf
  5. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-32.pdf
  6. https://doi.org/10.6028/NIST.SP.800-12r1
  7. https://ieeexplore.ieee.org/document/1055638
  8. https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture12.pdf
  9. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-133.pdf
  10. https://www.cs.purdue.edu/homes/ninghui/courses/Fall05/lectures/355_Fall05_lect33.pdf
  11. https://csrc.nist.gov/files/pubs/fips/196/final/docs/fips196.pdf
  12. https://www.cs.purdue.edu/homes/ssw/cs355/new8.pdf
  13. https://datatracker.ietf.org/doc/html/rfc4880
  14. https://people.eecs.berkeley.edu/~pister/290Q/Papers/Security/EnergyPaper.pdf
  15. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf
  16. https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/random-number-generators
  17. https://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-212.pdf
  18. https://web.williams.edu/Mathematics/lg5/302/RSA.pdf
  19. https://doi.org/10.6028/NIST.SP.800-133r2
  20. https://www.debian.org/security/2008/dsa-1571
  21. https://doi.org/10.6028/NIST.SP.800-57pt1r5
  22. https://datatracker.ietf.org/doc/html/rfc8017
  23. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
  24. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-106.pdf
  25. https://www.rfc-editor.org/rfc/rfc8446.html
  26. https://datatracker.ietf.org/doc/html/rfc8551
  27. https://csrc.nist.gov/pubs/fips/196/final
  28. https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186-4.pdf
  29. https://bitcoin.org/bitcoin.pdf
  30. https://datatracker.ietf.org/doc/html/rfc5280
  31. https://www.cisa.gov/news-events/news/understanding-digital-signatures
  32. https://www.sectigo.com/resource-library/digital-signature-legal-requirements
  33. https://cryptobook.nakov.com/asymmetric-key-ciphers
  34. https://www.aspencrypt.com/crypto101_public.html
  35. https://datatracker.ietf.org/doc/rfc9180/
  36. https://developers.google.com/tink/key-concepts
  37. https://datatracker.ietf.org/doc/html/rfc8446
  38. https://datatracker.ietf.org/doc/html/rfc4253
  39. https://datatracker.ietf.org/doc/html/rfc4252
  40. https://datatracker.ietf.org/doc/html/rfc7296
  41. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt3r1.pdf
  42. https://csrc.nist.gov/csrc/media/events/physical-security-testing-workshop/documents/papers/physecpaper19.pdf
  43. https://paulkocher.com/doc/TimingAttacks.pdf
  44. https://paulkocher.com/doc/DifferentialPowerAnalysis.pdf
  45. https://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf
  46. https://www.jsums.edu/nmeghanathan/files/2015/05/CSC437-Fall2013-Module-2-CryptographicTools.pdf
  47. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
  48. https://csrc.nist.gov/projects/cryptographic-module-validation-program
  49. https://oaktrust.library.tamu.edu/bitstream/handle/1969.1/195007/Module%25207%2520Public%2520Key%2520Infrastructure.pdf?sequence=8&isAllowed=y
  50. https://www.directives.doe.gov/directives-documents/200-series/0200.1-DManual-1Chapter09/%40%40images/file
  51. https://www.wired.com/2011/09/diginotar-bankruptcy/
  52. https://digitalcommons.usf.edu/cgi/viewcontent.cgi?article=1246&context=jss
  53. https://jhalderm.com/pub/papers/misissuance-sp18.pdf
  54. https://arxiv.org/abs/1806.03160
  55. https://news.mit.edu/2020/protecting-sensitive-metadata-from-surveillance-0226
  56. https://www.ncsc.gov.uk/collection/in-house-public-key-infrastructure/pki-principles/protect-your-private-keys
  57. https://arxiv.org/abs/2405.13310
  58. https://pi.math.cornell.edu/~morris/135/Bacon.pdf
  59. https://pages.cs.wisc.edu/~rist/642-spring-2014/shannon-secrecy.pdf
  60. https://cryptocellar.org/cesg/ellis.pdf
  61. https://ethw.org/Milestones:Invention_of_Public-key_Cryptography%2C_1969_-_1975
  62. https://cryptocellar.org/cesg/cocks.pdf
  63. https://cryptocellar.org/cesg/williamson.pdf
  64. https://patents.google.com/patent/US4405829A/en
  65. https://www.fundinguniverse.com/company-histories/rsa-security-inc-history/
  66. https://www.rfc-editor.org/rfc/rfc8017.html
  67. https://evervault.com/papers/koblitz.pdf
  68. https://evervault.com/papers/miller.pdf
  69. https://csrc.nist.gov/projects/elliptic-curve-cryptography
  70. https://csrc.nist.gov/pubs/sp/800/56/a/r3/final
  71. https://csrc.nist.gov/pubs/fips/186-5/ipd
  72. https://cacr.uwaterloo.ca/hac/about/chap3.pdf
  73. https://people.csail.mit.edu/alinush/6.857-spring-2015/papers/elgamal.pdf
  74. https://users.cs.duke.edu/~reif/courses/randlectures/Quantum.papers/shor.factoring.pdf
  75. https://ieeexplore.ieee.org/document/365700
  76. https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization
  77. https://csrc.nist.gov/projects/post-quantum-cryptography/round-4-submissions
  78. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
  79. https://www.nist.gov/news-events/news/2024/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption
  80. https://csrc.nist.gov/projects/post-quantum-cryptography
  81. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
  82. https://www.nccoe.nist.gov/sites/default/files/2022-06/Migration-to-PQC-05-16.pdf
  83. https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
  84. https://www.researchgate.net/publication/376618031_How_Artificial_Intelligence_become_a_threat_to_cryptography-A_systematic_literature_review
  85. https://sepiocyber.com/resources/research/supply-chain-attacks/
  86. https://www.sandboxaq.com/post/cryptography-a-forgotten-part-of-software-supply-chain-security
  87. https://qt.eu/
  88. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines
  89. https://www.cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001
  90. https://pqcc.org/wp-content/uploads/2025/05/PQC-Migration-Roadmap-PQCC-2.pdf
  91. https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/
  92. https://www.ncsc.gov.uk/whitepaper/next-steps-preparing-for-post-quantum-cryptography
Add your contribution
Related Hubs
User Avatar
No comments yet.