How Does Public-Key Cryptography Work? Keys, Encryption, and Signatures
You have probably used public-key cryptography today without seeing a key. It helps your browser connect securely to websites, allows software to verify updates, helps you sign in with a passkey, and lets a cryptocurrency wallet authorize transactions. But how does public-key cryptography work when one of its keys is available to everyone?
The short explanation is that the two keys are mathematically related but perform different jobs. Sharing the public key does not normally reveal the private key when a properly chosen scheme is implemented correctly. What each key actually does depends on whether the system is encrypting information, verifying a digital signature, or establishing a shared secret. Treating those three jobs as interchangeable leads to many confusing explanations.What to remember
- Public means shareable, not necessarily verified: you still need to know whose key you received.
- Encryption protects content; a digital signature helps check origin and integrity. A signature does not hide its message.
- Modern HTTPS establishes session keys, then uses efficient symmetric encryption for application data.
- Crypto wallets generally use private keys to sign transactions; they do not “decrypt coins.”
- Algorithms, software, identity checks, and safe storage all matter as much as the idea of two keys.
What are a public key and a private key?
A cryptographic key is data an algorithm uses to perform a security operation. In an asymmetric system, the two keys form a pair. The public key is intended to be distributed. Its partner, the private key, must remain under the owner’s control. The NIST glossary describes these as separate keys used for complementary operations such as encryption and decryption or signing and verification.
A useful comparison is a publicly available way for other people to interact with you securely, paired with a private capability that only you control. The analogy has limits: public keys are not universal padlocks, and the mathematics and permissible operations vary by algorithm. An RSA encryption key, a digital-signature key, and a Diffie–Hellman-style key agreement do not all behave like the same reversible box.
Software creates keys using a cryptographically secure source of randomness and the rules of a chosen algorithm. The public key is calculated from the private-key material in many familiar schemes. Correct key generation makes obtaining the private key from the published public key computationally infeasible for the intended security level. That is a security assumption about particular schemes and computing capabilities, not a promise that every implementation is safe forever.A family of cryptographic techniques using distinct but related keys for complementary tasks. Depending on the scheme, the keys may support public-key encryption, digital signatures, or key agreement.
Does a public key reveal a private key?
With a sound scheme, suitable parameters, and properly generated keys, publishing the public key is part of the design. The practical danger is more often a stolen private key, weak randomness, flawed software, or believing an attacker’s substituted public key belongs to the intended person. Advances in computing also affect which algorithms remain appropriate over time.
The word “public” does not necessarily mean anonymous. Reusing a public key or address in a system with public transaction records can make activity easier to connect. Privacy is separate from the ability to verify a signature.
How does public-key encryption work? A simple example
Imagine that Maya wants to receive a confidential message from Luis. Maya generates an encryption key pair and gives Luis her authentic public encryption key. Luis uses a suitable encryption system to protect the message with that public key. He sends the resulting ciphertext across a network. Maya uses the matching private key to recover the plaintext.
Sending a protected message
- Obtain the right public key: Luis checks that the encryption key is Maya’s, rather than accepting an unverified copy.
- Encrypt or establish a content key: Software uses the recipient’s public-key system to protect the message, often by deriving or encapsulating a temporary symmetric key.
- Send the ciphertext: Luis can send the protected result over a channel others might observe.
- Decrypt privately: Maya uses her private key and the scheme’s required inputs to recover the message or content key.
In practice, efficient designs commonly combine asymmetric and symmetric cryptography. The public-key part establishes or protects a temporary shared secret; a symmetric algorithm uses that secret to encrypt the actual data. RFC 9180 describes a standard hybrid public-key encryption construction. It is a concrete example of why the familiar explanation “the public key encrypts the whole file” can be misleading.
What this example does not prove: Confidentiality alone does not establish who sent the message. Nor does encrypting a message automatically protect its metadata, such as the fact that two parties communicated. The complete protocol must address authentication, integrity, and metadata exposure according to the use case.
How do digital signatures work?
A digital signature solves a different problem: how can a recipient check that a particular holder of a private signing key authorized a particular message? The sender’s software signs the message, often after hashing it according to the specified signature algorithm. A verifier uses the corresponding public verification key to check the signature against that exact message. Changing the signed contents should cause verification to fail.
For a simple example, imagine a software publisher releasing an update. It signs the update with a private signing key. A user’s device checks the signature using a trusted public key. If the file was changed after signing, verification fails. But the device also needs a trustworthy way to obtain the publisher’s verification key; a mathematically valid signature under an unknown attacker’s key does not prove publisher identity. NIST’s Digital Signature Standard defines approved signature methods and their use for detecting unauthorized modifications and authenticating a claimed signatory.
Three different jobs for public-key systems
| Job | What the pair does | Main result |
|---|---|---|
| Public-key encryption | Recipient’s public key protects a message or content key; matching private key recovers it. | Confidentiality, if implemented correctly. |
| Digital signature | Signer’s private key produces a signature; public key checks it against the message. | Evidence of authorization by the key holder and message integrity, provided the key is trusted. |
| Key agreement | Participants use their own secret values and exchanged public values to derive shared secret material. | Material for later symmetric protection; identity needs separate authentication. |
Are a public key and a digital signature the same thing?
No. A public key is key material used for a defined operation. A signature is an output calculated for a particular message using a signing key. Verification requires the correct message, signature, public key, and algorithm. Sharing your public key is generally expected; sharing a usable private signing key would let someone else produce signatures under that key.
How does key agreement differ from encryption?
In key agreement, participants use private contributions and exchange corresponding public information to calculate matching shared secret material. The intention is that an eavesdropper who only sees the public exchange cannot feasibly calculate the same secret. The secret can then be used to derive keys for a symmetric cipher.
Can you see the mathematics with small numbers?
Here is a toy Diffie–Hellman example. Both people publicly agree on the number 23 and a starting value of 5. Alice secretly picks 6 and publishes the result of raising 5 to the sixth power and taking the remainder after division by 23: 8. Bob secretly picks 15 and publishes the corresponding result: 19. Alice takes Bob’s 19, raises it to her secret 6, and takes the remainder after division by 23. Bob does the matching calculation with Alice’s 8 and his secret 15. Both get 2. They arrived at the same value without broadcasting their private choices.
Those numbers are deliberately tiny: an observer could easily test guesses and recover the secrets. Real systems use appropriately chosen algorithms and far larger parameters. This example shows the shape of key agreement, not a secure protocol or a way to encrypt a message directly. It also does not establish who Alice or Bob is.
This matters because HTTPS is often illustrated as “the browser encrypts everything with the website’s public key.” That picture misses how contemporary TLS 1.3 works.
How does public-key cryptography work in HTTPS?
When your browser opens a site over HTTPS, TLS negotiates the connection. In the certificate-authenticated case, the browser checks a certificate chain and the website’s identity for the requested hostname; the server proves possession of the corresponding private signing key during the handshake. The participants establish shared keying material and derive symmetric keys for protecting subsequent traffic. The current TLS 1.3 specification, RFC 9846, describes the handshake, authentication, and protected record layer. It superseded RFC 8446 in 2026.
TLS has other authentication arrangements and implementation details; the description above is the common certificate-based website case, not a claim that every TLS connection follows identical steps. Public-key techniques help establish and authenticate the connection. Symmetric encryption handles the application data stream efficiently.
A padlock or HTTPS address tells you the connection has been set up to protect data in transit to the named endpoint. It does not by itself prove that a merchant is honest, that the site cannot mishandle your information, or that you are on the business’s intended domain. A deceptive site can also use HTTPS.
How does a browser know which public key is the right one?
In the usual web model, the server presents a certificate that links a public key to a domain name through a certificate chain. The browser checks that chain against its trusted authorities and verifies that the certificate applies to the requested hostname. If the validation fails, the browser can show a security warning. This mechanism binds a key to a domain, not a guarantee about the site’s business practices.
Outside the web, the answer may be different: a person might compare a key fingerprint through a trusted channel, use an organization’s published key directory, or rely on an application’s established identity system. Without this step, an attacker can replace a public key and intercept communication even if the encryption mathematics itself is sound.
Where else do you use this? Passkeys
A passkey is a familiar example of signing for authentication, rather than encrypting a message for secrecy. When you register a passkey with a service, the service receives a public credential, and your device or credential provider protects the corresponding private key. During sign-in, the service sends a fresh challenge tied to the sign-in flow; your authenticator responds using the private key, and the service checks the response with the registered public key. The website never receives the private key. The FIDO Alliance’s passkeys guide explains the public-key basis and how credentials can be used across supported devices.
Your fingerprint, face scan, or device PIN may unlock local use of a passkey. It is not the public key and, in the usual design, it is not sent to the site as the secret needed for verification. A passkey can still be affected by account-recovery weaknesses, compromised devices, or poor service integration; “uses public-key cryptography” is a design benefit, not a universal guarantee.
How do cryptocurrency wallets use the keys?
In many cryptocurrency systems, a private key authorizes a transaction with a digital signature. Other participants or network software verify that signature using the corresponding public-key information and the chain’s transaction rules. Ethereum’s account documentation explains that a private key signs transactions, while Bitcoin’s explanation of wallets likewise links private keys to transaction signatures.
A wallet does not store coins inside the key. It manages access to credentials for assets tracked by the network’s ledger. Public keys, addresses, and recovery phrases are related but not interchangeable. An address may be derived from a public key or related account data according to the network’s rules; the exact format varies by chain and address type. A recovery phrase may be used by a particular wallet design to reconstruct key material. Never assume one chain’s key or address procedure applies to every other chain.
Someone can generally receive funds through public receiving information without giving the sender a private key. In contrast, a person with a usable private key or recovery phrase may be able to authorize transfers. This is why a claimed support agent or “recovery expert” asking for those secrets is a serious warning sign. Pointed Editorial’s guide to finding a legitimate crypto recovery provider explains that tracing a transaction is different from gaining access to a wallet and that a provider should not request a seed phrase or private key merely to trace public transactions.
Does knowing a wallet address let someone steal the funds?
A public address alone should not let anyone sign a transaction. It may, however, reveal transaction history or balance information on a transparent chain, depending on the network and how the address is used. Sending to the wrong address may be difficult or impossible to reverse. Always verify the entire address or an authenticated contact method, especially when copying it from a message or website.
Symmetric versus asymmetric cryptography: which is better?
They serve different tasks and often work together. Symmetric cryptography uses the same shared secret, or closely related secret material, to encrypt and decrypt. It is efficient for protecting ongoing data traffic, but the parties need a safe way to establish and manage the secret. Asymmetric methods enable useful operations with publicly shared material, including signatures and key establishment, but are comparatively complex and typically not used to encrypt every byte of a large data stream.
Asking which is “stronger” without specifying algorithms, parameters, protocol, and threat model has no reliable one-word answer. A correctly designed system often combines both. HTTPS is a familiar example: authenticated key establishment sets up a secure channel; symmetric keys protect the bulk traffic.
What can go wrong even if the mathematics is sound?
Protect the key and verify the identity
If an attacker gets a private key, tricks you into using a substitute public key, or controls the device doing the cryptographic work, the underlying algorithm may still be secure while your account or message is exposed. Use reputable, updated software; protect private-key backups and recovery phrases; and independently check the identity of sensitive recipients.
A private key can leak through phishing, malware, screenshots, unsafe backups, a compromised extension, or accidental sharing. The public key itself does not tell you whether the other person is trustworthy. Bad randomness or incorrect protocol design can also break security despite impressive-sounding algorithms.
The practical response depends on the system. If a cryptocurrency wallet’s secret is exposed, moving assets to a newly secured wallet may be urgent, but fees and chain rules apply. If a website certificate or organizational key is compromised, the organization must replace or revoke it as appropriate and investigate what happened. Do not copy an online “fix” blindly into an active wallet or production server.
What about quantum computers?
The security of widely deployed classical public-key schemes depends on mathematical problems that large enough fault-tolerant quantum computers could undermine. That does not mean a publicly available quantum computer can currently read every encrypted message or empty every wallet. The timing and practical impact depend on the algorithm, protocol, exposure, and future capabilities.
NIST finalized its initial post-quantum standards in 2024: FIPS 203 for ML-KEM key establishment, and FIPS 204 and 205 for digital signatures. Organizations need to assess where vulnerable public-key algorithms are used and plan migrations. Readers should not assume that a different name on a marketing page means a product has deployed a secure post-quantum protocol.
Conclusion
How does public-key cryptography work? It lets systems share useful key material without sharing every secret. A public key can help someone encrypt for a recipient, verify a signer’s message, or participate in establishing a shared secret, depending on the algorithm. The private key must be protected, and the public key must be tied to the correct person or service. Understanding those separate jobs makes HTTPS, passkeys, signed software, and crypto wallets much easier to evaluate. If you use a wallet, start by checking how it backs up keys and never disclose its recovery phrase to someone offering help.Can anyone use my public key?
Generally, yes, for the operations the key is intended to support: encrypting to you, verifying a signature, or participating in a specified protocol. That does not grant access to the matching private key. Be careful about privacy if a published key or address links your activities.
Can I decrypt a message with a public key?
In the usual public-key encryption example, the recipient’s private key is needed to decrypt. A public key can verify a digital signature, but verification is not decryption and does not reveal hidden text.
Does signing a document keep it secret?
No. A signature provides a way to check a message against the claimed signer’s key and detect changes. Encrypt the document as well if its contents must remain confidential.
Are a cryptocurrency wallet address and a public key identical?
Not necessarily. Address formats and derivation rules differ across networks. An address is receiving or account information; the public key is cryptographic key material. Check the relevant chain’s documentation before treating them as interchangeable.
Can a private key be recovered from its public key?
Properly generated keys used with sound current schemes are designed to make that computationally infeasible with relevant classical attacks. Weak algorithms, compromised software, poor randomness, and future advances can change the risk.
Is HTTPS the same as public-key encryption?
No. HTTPS commonly uses TLS, which combines authenticated key establishment with symmetric protection for ongoing traffic. Its exact operation depends on the negotiated mode; the site’s public key does not simply encrypt the entire browsing session.