Asymmetric Encryption & PKI

Asymmetric (public-key) cryptography uses a mathematically linked keypair: a public key you can hand to anyone, and a private key you guard with your life. What one key locks, only the other can unlock.

The classic intuition is a mailbox with a public slot. Anyone can drop a letter through the slot (encrypt with your public key), but only the person holding the mailbox key can open it and read the mail (decrypt with the private key). Crucially, being able to put mail in gives no ability to take mail out — the two operations are genuinely different.

This is slower than symmetric encryption by orders of magnitude, so in practice it is almost never used to encrypt bulk data directly. Instead it does two priceless jobs: key establishment (safely agreeing on a symmetric key with a stranger, solving the key distribution problem) and digital signatures (proving who sent something and that it was not altered). Nearly every secure system you touch combines asymmetric crypto for setup with symmetric crypto for speed.

Public-key systems rest on trapdoor functions: math that is easy to compute one way and infeasible to reverse without a secret.

RSA leans on factoring. Multiplying two enormous prime numbers together is trivial; taking the product and recovering the original primes is, for large enough numbers, computationally hopeless with classical computers. Your public key is built from the product; your private key depends on knowing the factors. Practical RSA today uses keys of 2048 or 3072 bits.

ECC (Elliptic Curve Cryptography) leans on a different hard problem: the difficulty of the elliptic-curve discrete logarithm. Its headline advantage is efficiency — a 256-bit ECC key offers security roughly comparable to a 3072-bit RSA key. Smaller keys mean faster math and less bandwidth, which is why modern TLS and mobile devices favor ECC. Common curves include NIST's P-256 and Daniel Bernstein's Curve25519.

Encryption hides content. Digital signatures do the opposite job — they make content verifiable. The keys are used in reverse: the signer processes a message with their private key, and anyone can check the result with the corresponding public key.

In practice you do not sign the whole message — you hash it first (see the next module) and sign the hash. A valid signature proves three things at once:

• Authenticity — it came from the holder of the private key.
• Integrity — the message was not altered, because any change breaks the hash and the signature no longer verifies.
• Non-repudiation — the signer cannot plausibly deny it, since only they hold the private key.

Signatures are the backbone of trust online: they authenticate software updates, sign TLS handshakes, secure code-signing and package managers, and validate the certificates we discuss next. Algorithms include RSA signatures, ECDSA, and EdDSA (Ed25519).

Public keys solve secrecy, but they create a new problem: when your browser receives a public key claiming to be your bank, how does it know the key really belongs to the bank and not an impostor? The answer is Public Key Infrastructure (PKI) and the certificate authority (CA).

A CA is a trusted third party that vouches for the binding between an identity and a public key by issuing a signed X.509 certificate. Your device ships with a built-in list of trusted root CAs. Roots rarely sign end-user certificates directly; instead they sign intermediate CAs, which sign the leaf certificate for an actual website. This is the chain of trust: your browser verifies the leaf was signed by an intermediate, the intermediate by a root, and the root is one it already trusts.

Each link is checked by verifying a digital signature. If any signature fails, the chain breaks and the connection is untrusted. This delegated model is what lets a browser trust hundreds of millions of websites it has never seen, by trusting a few hundred CAs.

The chain of trust has a terrifying property: any trusted CA can issue a valid certificate for any domain. Your browser trusts hundreds of them, and each is a single point of failure for the entire web. Compromise one CA and you can impersonate anyone.

This is not hypothetical. In 2011 the Dutch certificate authority DigiNotar was breached. The attacker issued more than 500 fraudulent certificates, including one for *.google.com. That certificate was then used in a large-scale man-in-the-middle attack against roughly 300,000 Gmail users in Iran — reading supposedly encrypted traffic in real time. When it came to light, browser vendors removed DigiNotar from their trust stores entirely, and the company collapsed into bankruptcy within weeks.