How Public-Key Cryptography Actually Works

Public-key cryptography is one of those ideas that feels almost magical when first explained and completely ordinary once you have used it for a few years. You generate a key pair. You share one half with the world. You keep the other half secret. People can now send you encrypted material or verify your signatures without ever seeing your private key. The magic fades into habit.

That habit can hide the mechanism. Engineers learn that TLS uses ECDHE, certificates carry public keys, software updates are signed, SSH hosts have key fingerprints, and passkeys rely on asymmetric credentials. But the pieces often remain disconnected. RSA becomes one box, elliptic curves another, signatures another, key exchange another, post-quantum migration a future headache somewhere off to the side.

This article puts the pieces back together. We will start with the problem public-key cryptography actually solved, then walk through the trapdoor idea, the mechanics of RSA and elliptic-curve systems, the difference between encryption, signatures, and key agreement, why forward secrecy needs ephemeral keys, where real implementations fail, and why the industry is already moving toward hybrid post-quantum designs.

The Problem Was Never Randomness. It Was Key Distribution

Symmetric cryptography is older, faster, and in many ways simpler than public-key cryptography. If Alice and Bob already share a secret key, they can encrypt traffic with AES-GCM or ChaCha20-Poly1305 very efficiently. They can authenticate messages with HMAC or GMAC. Modern symmetric primitives are excellent.

The problem is in the phrase "already share".

If two parties have never met, how do they agree on a secret key without exposing it to anyone listening? In a small environment you can use couriers, sealed envelopes, hardware tokens, or pre-shared keys. Military systems did this for decades. So did early telecoms and banking networks.

At internet scale, pre-shared symmetric keys collapse operationally.

• every pair of parties would need a unique secret or they would become impersonable
• rotating one relationship's key would require a secure out-of-band channel
• compromise of one shared key would allow both decryption and forgery by either holder
• adding a million new users would mean provisioning and protecting a million shared secrets

Public-key cryptography changed the cost structure of that problem. Instead of establishing a secret with every peer in advance, a party can publish a public value and keep a private value. Different schemes then let peers do one of three broad things:

• encrypt something that only the private-key holder can recover
• verify that only the private-key holder could have produced a signature
• combine public and private material to derive a shared secret without sending it directly

That is why asymmetric cryptography matters. It is not "stronger crypto" than symmetric algorithms. In most deployments it is the bootstrapping layer that makes symmetric crypto usable between parties that did not already share a secret.

Trapdoor Design Means Easy in One Direction, Hard in Reverse

The intellectual core of public-key cryptography is not "two keys". It is a trapdoor one-way function or, more broadly, a trapdoor mathematical problem.

You want an operation that is easy to compute in the forward direction but hard to reverse unless you know special information.

For RSA, the structure is arithmetic modulo a composite number n = p * q, where the trapdoor is the factorisation into p and q.

For Diffie-Hellman style systems, including elliptic-curve variants, the structure is repeated group operations where the trapdoor problem is discrete logarithm: given a base point G and a public point Q = x * G, recover x.

The details differ, but the pattern is the same:

• key generation creates a hard problem instance
• the public key exposes the hard problem instance
• the private key is the trapdoor that makes some inverse or related operation feasible

This is why public-key systems are so sensitive to mathematical assumptions. With symmetric ciphers, the attacker is generally trying to brute-force a key or exploit a design weakness in a permutation or stream generator. With asymmetric systems, the attacker is often attacking a very specific number-theoretic problem. If that problem becomes easy, the whole scheme falls over.

The coming post-quantum transition is a good example. RSA and classical Diffie-Hellman are not failing because their implementations suddenly got sloppy. They are under long-term pressure because Shor's algorithm would make their underlying hard problems easy on a sufficiently capable quantum computer.

RSA Turns Modular Arithmetic Into a Trapdoor

RSA is still the best-known public-key algorithm family, even though modern transport protocols increasingly prefer elliptic-curve systems for key agreement and signatures.

The key generation process is conceptually straightforward.

1. Pick two large random primes p and q.
2. Compute n = p * q.
3. Compute Euler's totient phi(n) = (p - 1)(q - 1).
4. Choose a public exponent e, usually 65537.
5. Compute the private exponent d such that e * d mod phi(n) = 1.

The public key is (n, e). The private key is d plus, in practice, the factors p and q for faster CRT-based operations.

Toy numbers make the mechanism easier to see, even though they are insecure.

Take:

• p = 61
• q = 53
• n = 3233
• phi(n) = 3120
• e = 17
• d = 2753

If the plaintext integer is m = 123, encryption computes:

c = m^e mod n = 123^17 mod 3233 = 855

Decryption computes:

m = c^d mod n = 855^2753 mod 3233 = 123

The reason this works is number theory: the exponents are chosen so that raising to e and then d returns the original value modulo n for valid message representatives.

Two practical lessons matter more than the toy arithmetic.

First, RSA is not secure because exponentiation is mysterious. It is secure because finding d from the public key is believed to be hard if you cannot factor n. If an attacker factors n, they can compute phi(n) and derive d.

Second, raw RSA is not what real systems use. Textbook RSA is deterministic and structurally unsafe. Real encryption uses padding such as OAEP. Real signatures use padding such as PSS. The padding is not optional decoration. It is part of the security proof.

That distinction produced some of the most famous practical failures in cryptography.

• Bleichenbacher's 1998 attack showed that tiny format-oracle differences around PKCS#1 v1.5 RSA decryption could leak enough information to decrypt chosen ciphertexts.
• Manger and later variants refined oracle attacks further.
• Signature forgeries have happened when systems used the wrong verification rules, accepted malformed ASN.1, or failed to check all padding bytes.

The lesson is blunt: a mathematically sound primitive can become an insecure protocol if its encoding and error handling are sloppy.

Elliptic Curves Shrink the Same Jobs Into Smaller Keys and Faster Handshakes

RSA dominated early web PKI partly because it was comparatively simple to understand and implement. Over time, elliptic-curve systems won enormous ground because they offer similar security at much smaller key sizes.

A 3072-bit RSA key is roughly in the same classical security range as a 256-bit elliptic-curve key. The exact comparison depends on the attack model, but the operational conclusion is clear.

• certificates get smaller
• signatures get smaller
• CPU cost often drops
• TLS handshakes carry fewer bytes
• embedded and mobile systems benefit immediately

The mathematics under the hood is different. Instead of modular exponentiation over integers modulo n, elliptic-curve cryptography works in a group of points on a curve over a finite field.

A curve such as Curve25519 gives you:

• a base point G
• a private scalar x
• a public point Q = x * G

The operation x * G means repeated group addition, implemented with efficient formulas rather than literal repeated addition. Given G and Q, recovering x is the elliptic-curve discrete logarithm problem.

This structure supports several important schemes.

• X25519 for key agreement
• Ed25519 for signatures
• ECDSA on curves such as P-256 for signatures
• ECDH/ECDHE on curves such as X25519 or P-256 for shared-secret derivation

Most engineers do not need to do curve arithmetic by hand, but they do need to understand what the public key actually represents. It is not a password-like blob. It is a group element produced by multiplying a base point by a secret scalar.

That detail explains several real implementation constraints:

• invalid-curve and small-subgroup attacks exist if you accept unvalidated peer points in the wrong protocols
• constant-time scalar multiplication matters because secret-dependent branches can leak key material
• a curve choice is a security and interoperability choice, not just a byte-length choice

Curve25519 and Ed25519 became popular partly because they were designed to avoid many sharp edges of older ECC deployments. They use rigidly specified parameters, efficient formulas, and comparatively implementation-friendly encodings. They did not make asymmetric crypto simple. They made it less error-prone.

Encryption, Signatures, and Key Agreement Are Different Jobs

One reason public-key cryptography feels confusing is that people talk about it as if it were one thing. It is really a family of tools doing three distinct jobs.

Public-key encryption

This is the pattern many people learn first. The sender encrypts with the recipient's public key, and only the recipient's private key can decrypt.

That is conceptually clean, but in modern protocols pure public-key encryption is rarely used to encrypt bulk data directly. The asymmetric operation is expensive and has message-size limits. Instead, the sender usually encrypts a randomly generated symmetric key or a short secret seed, then bulk encryption happens symmetrically.

Historically, TLS before 1.3 could use RSA key transport like this: the client generated a premaster secret, encrypted it with the server's RSA public key, and sent it to the server. That works, but it lacks forward secrecy if the long-term RSA private key is later compromised.

Digital signatures

Signatures reverse the trust direction. The signer uses the private key to produce a value that anyone with the public key can verify.

This gives you authenticity and integrity, not confidentiality.

Software distribution, Git commit signing, package registries, firmware updates, and certificates all rely on this split. The verifier does not need the signing secret and therefore cannot forge signatures. That separation is what a shared-key MAC cannot provide.

Key agreement

In Diffie-Hellman style key agreement, both parties contribute public values derived from private secrets and combine them to arrive at the same shared secret independently.

For classic finite-field DH, the pattern is:

A publishes g^a mod p
B publishes g^b mod p
A computes (g^b)^a mod p = g^(ab) mod p
B computes (g^a)^b mod p = g^(ab) mod p

Elliptic-curve Diffie-Hellman does the analogous thing with scalar multiplication on a curve.

TLS 1.3 typically uses an ephemeral ECDHE exchange such as X25519 to derive a shared secret, then symmetric keys are expanded from that secret using HKDF. The server's certificate key is still used, but only for authentication through a signature over the handshake transcript, not for bulk key transport.

Keeping those jobs separate clears up a lot of protocol design:

• key agreement usually creates the secret for this session
• signatures authenticate the parties or artefacts involved
• symmetric crypto carries the real traffic efficiently

Forward Secrecy Appears Only When the Session Secret Is Ephemeral

Forward secrecy is one of the most important practical gains from modern public-key protocol design.

The property is simple to state: if an attacker records today's encrypted traffic and steals a long-term private key next year, they still should not be able to decrypt the old traffic.

RSA key transport does not provide that property. If the server's long-term RSA private key is later stolen, any recorded handshake that carried an RSA-encrypted premaster secret can be replayed offline and decrypted.

Ephemeral Diffie-Hellman does better.

A modern TLS 1.3 style handshake looks roughly like this:

1. client sends supported cipher suites and a fresh ephemeral key share, often X25519
2. server replies with its own ephemeral key share
3. both sides derive the same shared secret
4. server signs the transcript with its certificate private key
5. symmetric handshake and application keys are derived from the shared secret and transcript hashes

The critical point is that the key agreement secret comes from ephemeral private values that exist only for this handshake. The certificate key authenticates the transcript, but it is not the thing that directly decrypts the session later.

So if the certificate private key leaks in 2027, the attacker still lacks the per-session ephemeral secrets from the recorded 2026 traffic.

This is why you will see terms such as:

• DHE: ephemeral finite-field Diffie-Hellman
• ECDHE: ephemeral elliptic-curve Diffie-Hellman
• static DH: long-term Diffie-Hellman keying, usually not what you want for forward secrecy

It also explains why engineers should be precise when they say "TLS uses RSA". A certificate may use RSA for signatures while the actual session key agreement is X25519. Those are different jobs inside the same handshake.

Signatures Fail Most Often at the Nonce, the Parser, or the Side Channel

Digital signatures are often presented as a clean private-key operation. In practice, the edge cases do the damage.

Nonce reuse in ECDSA

ECDSA signatures require a per-signature secret nonce k. If k is reused across two different messages signed with the same private key, the private key can often be recovered algebraically.

That failure is not theoretical. Sony's PlayStation 3 signing fiasco became the canonical public example. The same k value was reused, which turned the signature equations into a solvable system.

The simplified structure of ECDSA is:

r = x-coordinate(k * G) mod n
s = k^-1 (H(m) + r * priv) mod n

Reuse k on two messages and the algebra starts cancelling in dangerous ways.

This is why deterministic nonce generation, as in RFC 6979, became standard practice for ECDSA libraries. EdDSA goes further and derives its nonce deterministically from the private key and message, which avoids depending on an external RNG for every signature.

Padding and parser bugs in RSA signatures

RSA signatures have historically suffered from verification implementations that accepted malformed encoded structures, skipped strict DER validation, or treated ASN.1 parsing too loosely. The mathematical primitive was not the weak point. The format validation was.

Side-channel leakage

Secret-dependent branches, cache behaviour, timing, power analysis, and fault injection all matter for asymmetric implementations because the operations are long, structured, and repeated.

• an HSM doing RSA CRT operations must defend against fault attacks that reveal prime factors
• a software ECDSA implementation must not branch on secret scalar bits in observable ways
• signature comparison and padding checks must avoid oracle behaviour

This is why high-level crypto guidance always sounds repetitive: use well-vetted libraries, pick modern safe primitives, and do not design your own message formats unless you absolutely must. The mistakes are usually in the glue.

Hybrid Encryption Is Why Public-Key Crypto Does Not Carry Bulk Traffic Directly

A common beginner picture of asymmetric encryption is: take the whole message, encrypt it with the public key, send it, done. Real systems almost never work that way for anything larger than a tiny secret.

There are three reasons.

First, public-key operations are expensive. An RSA private-key operation or an elliptic-curve scalar multiplication is vastly slower than symmetric block or stream encryption.

Second, many public-key schemes have message-size limits. RSA-OAEP can encrypt only a payload smaller than the modulus size minus padding overhead. With a 2048-bit RSA key, the practical payload limit is a couple of hundred bytes, not a 20 MiB document.

Third, symmetric ciphers provide features such as authenticated encryption with associated data at speeds asymmetric systems cannot approach.

So real protocols use a hybrid pattern.

1. Generate a random symmetric session key.
2. Protect that small key using a public-key mechanism.
3. Encrypt the actual payload with the symmetric key.

This is what PGP does for email and file encryption. It is what many KMS envelope-encryption systems do inside cloud platforms. It is also conceptually what TLS does, except that TLS derives the symmetric keys from a key-agreement exchange rather than shipping a pre-generated session key in one direction.

Envelope encryption in a cloud service often looks like this:

plaintext data
   -> encrypt with random AES data key
ciphertext data + wrapped data key
   where wrapped data key = KMS public-key-like protection or KMS-managed key wrapping

The data key does the heavy lifting. The public-key or KMS step protects the small thing that really matters.

Once you see public-key crypto as a way to protect small high-value secrets rather than bulk payloads, a lot of system design becomes more intuitive.

Diffie-Hellman Is Easier To Understand Once You Walk One Toy Exchange

RSA gets most of the fame, but Diffie-Hellman style key agreement is what powers much of modern transport security. The key idea is subtle: the two parties never send the final shared secret. They each send public values that can be combined with their own private secret to derive the same result.

A toy finite-field example helps.

Take a prime p = 23 and a generator g = 5.

• Alice chooses private a = 6 and publishes A = g^a mod p = 5^6 mod 23 = 8
• Bob chooses private b = 15 and publishes B = g^b mod p = 5^15 mod 23 = 19

Now Alice computes:

shared = B^a mod p = 19^6 mod 23 = 2

Bob computes:

shared = A^b mod p = 8^15 mod 23 = 2

They arrive at the same value without ever sending 2 directly.

An eavesdropper sees p, g, A, and B, but not a or b. Recovering the shared secret means solving discrete logarithm or an equivalent hard problem under the scheme's assumptions.

Elliptic-curve Diffie-Hellman does the same conceptual job with point multiplication instead of modular exponentiation. X25519 is just a very well-engineered modern instantiation of that idea.

The beauty of the pattern is operational as well as mathematical. Each side can generate a fresh private value for each session, publish only the matching public value, and discard the private value after use. That is the engine behind forward secrecy.

Real Certificate-Based Protocols Usually Split Authentication and Key Establishment

A modern TLS 1.3 connection is a good case study because it uses public-key cryptography in two separate ways in the same handshake.

1. The client and server perform ephemeral key agreement, often X25519, to derive a shared secret.
2. The server proves identity by signing the handshake transcript with the private key corresponding to its certificate.

Those are different keys in a logical sense even if they both sit in the same certificate-and-handshake story.

The ECDHE exchange answers, "can we derive fresh symmetric keys for this session?"

The signature answers, "is the party who sent this ephemeral key share actually the holder of the long-term identity key bound to api.example.eu by the certificate chain?"

This separation is one of the best design improvements in mainstream secure transport. It means the long-term key is mainly an authentication anchor, while the session confidentiality rides on fresh ephemeral secrets.

The same pattern shows up elsewhere.

• Signal and related messaging protocols authenticate long-term identity keys but use ephemeral key agreement to create message or session keys.
• WireGuard uses static public keys for peer identity and ephemeral material for transport session freshness.
• Modern SSH can authenticate a host with a long-term host key while using ephemeral key exchange for the transport keys.

If a system uses one long-term key for every job, ask what happens after compromise. Splitting authentication from key establishment usually gives you a much better answer.

Private-Key Operations Are Often Accelerated With CRT, Blinding, and Hardware Controls

At the implementation level, even a familiar algorithm like RSA contains important engineering tricks.

A naïve RSA private-key operation computes c^d mod n directly. That works, but it is slower than necessary. Practical implementations usually keep the prime factors p and q and use the Chinese Remainder Theorem to speed up decryption or signing.

Instead of one large exponentiation modulo n, the implementation computes:

• one exponentiation modulo p
• one exponentiation modulo q
• then recombines the results with CRT

That can make RSA private-key operations several times faster.

But CRT introduces another concern: fault attacks. If an attacker can induce an error in only one side of the CRT computation and observe the faulty output, they may be able to recover one of the prime factors and break the key completely. This is why serious RSA implementations use consistency checks and why HSM designs care about physical fault resistance.

Blinding is another critical defence. In RSA blinding, the implementation randomises the input before private-key exponentiation and removes the randomisation afterwards. This helps protect against timing and power-analysis attacks that would otherwise observe patterns in repeated operations on chosen inputs.

These details are easy to ignore when consuming a library, but they explain why asymmetric cryptography is such a poor candidate for amateur reimplementation. The outer formula is the easy part. The side-channel and fault model are where mature implementations earn their keep.

A Public Key Needs an Identity Story Before It Becomes Trustworthy

A raw public key tells you how to verify or derive something. It does not tell you whose key it is.

That identity problem is solved differently in different ecosystems.

• Web PKI uses X.509 certificates and CA-issued chains.
• SSH often starts with TOFU, trust on first use, backed by host key fingerprints or managed known-hosts distribution.
• Software package systems ship embedded signing roots or pinned repository keys.
• WebAuthn binds public keys to origin and authenticator metadata rather than general-purpose CA hierarchies.

The important point is that public-key cryptography alone does not provide identity. It provides a mechanism that becomes meaningful only once some higher-layer system binds a name, device, service, or principal to the public key.

That is why certificate management and trust stores are not a side issue. They are the answer to the question, "whose key is this?" If that answer is wrong, perfect signature verification still authenticates the wrong party.

A PEM file illustrates the difference between representation and trust nicely:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt8...
-----END PUBLIC KEY-----

That blob may parse cleanly. It may even verify a signature. None of that means you should trust it for api.example.eu unless some binding layer says you should.

Real Systems Fail on Encoding, Storage, Rotation, and Cost

Operationally, public-key cryptography has a longer tail than the core maths suggests.

Encoding and format drift

Teams mix up PKCS#1, PKCS#8, SPKI, PEM, DER, JWK, and proprietary encodings more often than they admit. The key bytes may be the same in spirit while the container format differs. Debugging usually begins only after one service says "invalid key" and another happily accepts the same file.

Key storage

A long-term signing key on a general-purpose filesystem is very different from a key in an HSM, TPM-backed slot, secure enclave, or KMS-backed signing service.

The underlying algorithm may be identical. The extraction risk, audit surface, and operational controls are not.

Rotation

Asymmetric keys last longer than symmetric session keys, which tempts organisations into treating them as semi-permanent. That is dangerous. Rotation plans need to exist before compromise or expiry arrives.

Rotation usually means more than generating a new key pair. It means:

• distributing new public material
• keeping old public material long enough to verify historic signatures or honour overlap windows
• reissuing certificates
• updating pins or allow-lists safely
• deciding what old artefacts remain valid and for how long

Performance

Public-key operations are much slower than symmetric ones. That shapes protocol design.

• do not encrypt 50 MiB payloads directly with RSA
• do not sign every log line with a heavyweight remote HSM operation if a batched Merkle design would do
• do not pretend key size choices are free on mobile or embedded hardware

The standard pattern remains hybrid for a reason. Use asymmetric crypto to authenticate and establish a symmetric secret. Then let symmetric crypto carry the actual data.

Hashing, Domain Separation, and Message Framing Matter as Much as the Key Math

A signature algorithm is rarely signing the raw application payload directly. It is usually signing a hash of a carefully structured message, and that structure matters.

If you sign raw bytes without a stable framing rule, subtle ambiguity bugs appear quickly.

Imagine a service that signs concatenated fields like this:

amount || currency || account

If lengths are not encoded, then 10|EUR|1234 and 1|0EUR|1234 can become the same byte stream under sloppy parsing rules. Real signature schemes are usually embedded in protocols that define canonical serialisation, domain separation, and context strings precisely because the cryptographic primitive only protects the bytes it is given. It does not protect your interpretation of those bytes.

Hashing sits in the middle of this.

For RSA signatures with PSS, the message is hashed and then encoded with randomness and padding before the private-key exponentiation. For ECDSA, the hash of the message participates in the s value computation. For Ed25519, hashing is part of nonce derivation and response calculation. In every case, the security proof assumes a particular message-to-bytes mapping and a particular hash usage pattern.

Domain separation is the discipline that stops one valid signature context from being replayed as another. A few examples:

• a certificate-signing request should not be interpreted as a software-update manifest
• a blockchain transaction signature should not be valid as a login challenge response
• an SSH host-key proof should not be accepted as a generic detached file signature

Well-designed protocols include an explicit context string, version prefix, or transcript label in the bytes being signed. TLS 1.3 does this heavily with transcript hashes and labelled HKDF expansions. Modern application protocols increasingly do the same because people learned the hard way that "sign the JSON" is not a complete specification.

The same issue appears in key derivation after public-key agreement. The shared secret that comes out of Diffie-Hellman is usually not used directly as an AES key. It is fed into a KDF such as HKDF along with transcript context, identities, nonces, or algorithm identifiers.

That KDF step is doing several jobs:

• extracting uniform key material from a shared secret that may not be evenly distributed enough on its own
• separating one derived key from another so that encryption keys, MAC keys, and exporter secrets do not collide
• binding the derived keys to the actual handshake transcript so that downgrade or transcript-splicing attacks become harder

Once again, the public-key primitive is only one layer. Secure systems live or die on how the output is framed, hashed, and derived into the next stage.

Curve and Parameter Validation Are Not Administrative Details

Cryptographic agility is sometimes treated like a configuration checkbox: choose RSA, P-256, X25519, or something post-quantum and move on. In practice, parameter and point validation can be the difference between a secure exchange and a key leak.

With finite-field Diffie-Hellman, groups must be chosen so that small-subgroup attacks do not let a malicious peer learn information about the other party's secret exponent. Safe-prime groups and subgroup checks exist for a reason.

With elliptic-curve systems, the peer's public point cannot always be accepted blindly. Depending on the curve model and protocol, invalid points or small-order points may let an attacker push the computation into a subgroup where repeated interactions leak secret information. X25519 is comparatively robust because of how the Montgomery ladder and cofactor behaviour are specified, but even then protocols still need to think clearly about contributory behaviour and key confirmation.

This is one reason modern guidance prefers well-specified named groups over ad hoc custom parameters. A rigid parameter set removes a whole class of design and interoperability mistakes.

The same principle applies to RSA key generation. Picking e = 65537 is not cargo cult. It gives a public exponent that is efficient and avoids several pathological cases associated with tiny exponents such as 3, which historically interacted badly with weak padding and message structure. Strong prime-generation, sufficient modulus size, and correct primality testing are all part of the security boundary too.

What looks like a parameter choice on a dashboard is often really a commitment to a particular attack surface.

In other words, parameter validation is not paperwork. It is part of the cryptographic proof boundary. When a library says "accept only named groups" or "reject malformed public keys", it is not being fussy. It is refusing to let attacker-controlled algebra change the problem you thought you were solving.

Quantum Pressure Is Changing the Roadmap Before It Changes the Exploitability

A useful way to think about the quantum threat is this: the industry has not changed direction because quantum computers can break deployed RSA-3072 today. It is changing direction because the migration lead time is long, the cryptanalytic consequence is severe, and stored ciphertext can be harvested now for decryption later.

Shor's algorithm would break RSA, finite-field Diffie-Hellman, and elliptic-curve Diffie-Hellman once quantum hardware reaches the right scale and error-correction maturity. That puts almost the entire classical public-key stack under eventual pressure.

The immediate response in transport protocols is not "throw away classical crypto tomorrow". It is hybrid key establishment.

A hybrid TLS or SSH design combines:

• a classical exchange such as X25519
• a post-quantum KEM such as ML-KEM, standardised by NIST from the Kyber family

The final shared secret is derived from both contributions. An attacker must break both components to recover the session key.

This buys three things at once:

• interoperability with today's systems and threat models
• a migration path for future post-quantum resistance
• protection against "harvest now, decrypt later" for traffic recorded today if the post-quantum side remains sound

Post-quantum signatures are the next wave after KEMs because they affect certificate sizes, firmware update channels, package managers, and every place where long-lived signed artefacts exist. The migration will be slower there because signature sizes, verification cost, and trust-store mechanics are harder to hide.

Public-Key Cryptography Is Best Understood as a Bootstrap Layer

Once you strip away the terminology and vendor packaging, the role of public-key cryptography becomes quite clear.

It is the bootstrap layer that lets strangers agree on secrets, verify authorship, and attach identity to communications without first sharing a password.

• RSA showed how modular arithmetic could create a practical trapdoor system
• elliptic-curve systems made key agreement and signatures smaller and faster
• ephemeral Diffie-Hellman gave mainstream protocols forward secrecy
• certificates and trust systems gave public keys operational meaning
• modern protocol design turned asymmetric crypto into a front end for symmetric traffic protection
• post-quantum work is now preparing to replace the mathematical assumptions under much of that machinery

That last point is worth ending on. Public-key cryptography is not one frozen invention from the 1970s. It is a stack of evolving designs built around specific hardness assumptions, specific encodings, and specific operational habits. When those assumptions or habits change, the stack changes with them.

If you remember only one practical rule, make it this one: the most important questions are rarely "RSA or ECC?" in the abstract. They are "what job is this key doing, what trust binds it to an identity, what leaks if it is stolen, and what happens to traffic or signatures created before that theft?"

Those questions are what separate a system that merely uses public-key cryptography from a system that understands it.