Public-key cryptography: which key opens a message?
Public-key cryptography uses pairs of related keys, with a public key that can be distributed openly and a corresponding private key that must remain secret. In an encryption system, anyone with the public key can turn a message into ciphertext. Recovering the original message requires the paired private key. Publishing the encryption key therefore makes it possible for people to send protected messages to its owner without giving them the means to read those messages afterward.
The contrast with symmetric cryptography helps explain the practical value of that arrangement. Before the mid-1970s, cipher systems used symmetric algorithms, with both sender and recipient using the same cryptographic key and keeping it secret. They had to exchange that key securely before using the system, perhaps through a secure channel. Organizing those exchanges becomes difficult as the number of participants rises, secure channels are unavailable, or keys change frequently. When messages must remain secret from other users, each possible pair of users needs a separate key. Open distribution of the public component changes the task of arranging communication.
Public-key cryptography has an illustration in a journalist's work. A journalist can publish an encryption public key on a website, allowing people to send confidential messages to the news organization as ciphertext. An eavesdropper reading those messages in transit cannot decrypt them; the journalist who holds the corresponding private key can. However, concealing message content does not conceal every detail of communication. Encryption alone does not hide which computer sent a message, when it was sent, or how long it is. Nor does encryption by itself establish who sent the message. Confidentiality and identification require separate attention.
Digital signatures use a related pair for a different purpose. A sender combines a private key with a message to create a signature, and anyone holding the corresponding public key can check whether that signature matches. The message itself need not be encrypted. A software publisher, for example, can include a public verification key in installed software and later distribute updates signed with its private key. Receiving computers can verify those signatures to confirm that an update is genuine. A forger without the signing private key cannot produce a message and signature pair that passes verification with the corresponding public key.
Public-key cryptography also includes key exchange. In the Diffie-Hellman scheme, each party generates a pair and distributes the public component. After obtaining authentic copies of each other's public keys, the parties can compute a shared secret offline. That secret can become the key for a symmetric cipher. Hybrid cryptosystems combine asymmetric and symmetric methods because asymmetric algorithms are generally much more computationally intensive. PGP, SSH, and the SSL/TLS family use hybrid procedures. The asymmetric stage avoids the need to transport a shared symmetric key manually, while symmetric cryptography provides higher data throughput during the remainder of the connection.
Authenticity becomes a distinct challenge when public keys circulate. A sender needs confidence that a key belongs to the person or organization named and has not been replaced by a third party. In a man-in-the-middle attack, an attacker intercepts the exchange and substitutes different public keys. To avoid suspicion, the attacker can intercept, decrypt, and encrypt messages again using the appropriate keys for separate communication segments. Open availability is therefore different from authentic ownership. The vulnerability lies in accepting a substituted key as belonging to the intended participant, rather than in simply allowing a genuine public key to be widely available.
Public-key cryptography can address ownership through a public key infrastructure, or PKI. Certificate authorities certify ownership of key pairs, and TLS relies on this approach. Those authorities must check the key holder's identity, establish that the public key is correct, and protect their own systems. Browsers use certificates from PKI providers to check authorities and then potential communicators. A compromised authority that issues a certificate for a bogus public key can enable interception. A web of trust offers another approach, using individual endorsements of connections between users and their public keys. PGP uses that method alongside domain name system lookup.
Keeping the private component secret remains a central security requirement. Disclosure can compromise the protections built around a key pair, while a poor algorithm choice or insufficient key length introduces additional weaknesses. Some schemes mitigate exposure with forward secrecy, generating ephemeral keys during communication that must also be known for that communication to be compromised. Implementations may also face side-channel attacks, which exploit leaked information to simplify the search for a secret key. Researchers study both those attacks and defenses against them.