This lesson quickly sets up, for the FOUNDATIONS level, a topic that PRACTITIONER and ADVISOR readers already know. The next lesson (shor-grover-resource-estimates) needs this distinction to explain why a quantum computer affects the two very differently. PRACTITIONER and ADVISOR readers can skip this lesson and go straight to the next one; that is why it is kept as a separate refresher, a step in the prerequisite chain that is required for FOUNDATIONS and optional for the other levels.
Two families, two different key models
Symmetric cryptography (AES is the most common example) uses the same key to encrypt and decrypt: you and the other party lock and unlock with one secret value you have shared in advance. It is fast and suits large volumes of data (encrypting a video stream or a file transfer, for example), but it has a problem: that key has to reach both sides safely, without anyone intercepting and copying it. How do you share that key safely, over the internet, with a server you have never met? That question is why asymmetric cryptography exists.
Asymmetric cryptography (RSA, ECC/ECDSA) uses a pair of keys: one public (the public key, which you can hand out freely) and one secret (the private key, which stays with you). A message encrypted with the public key can only be decrypted with the matching private key; or the other way round, something “signed” with the private key can be verified with the public key. This solves secure communication with someone you have never met, but it rests mathematically on a “hard problem”. RSA relies on how hard it is to factor a very large number into primes (the larger the number, the longer this takes a classical computer). ECC (Elliptic Curve Cryptography) relies on the hardness of a problem called the “discrete logarithm” on a special mathematical structure called an elliptic curve. Note the name, because you will meet it again in the next lesson; roughly, it means “finding how many steps it takes to get from one point on the curve to another takes a classical computer impractically long”.
Why this distinction matters
As the next lesson shows, Shor’s algorithm targets exactly these “hard problems” behind asymmetric cryptography (factoring, discrete logarithms) and solves them at a speed classical computers cannot. Grover’s algorithm touches symmetric cryptography in a different, much milder way. Without this difference, the sentence “a quantum computer breaks cryptography” means nothing; the real question is which cryptography, and how much, and nearly this whole course is spent answering it.
In practice they work together: the TLS example
When you connect to a website over https://, the two families come in one after the other. First the handshake: your browser uses the public key in the site’s certificate to verify that the site really is who it claims to be (asymmetric cryptography, with RSA or ECDSA signatures), and the two sides agree on a shared temporary key (also an asymmetric mechanism, key exchange). After the handshake, the actual data traffic (page content, forms, whatever you send and receive) is encrypted symmetrically with that temporary key (such as AES-GCM), because symmetric cryptography is much faster and practical for large volumes.
In the rest of this course, when we say “PQC” we almost always mean that handshake side: new algorithms that replace asymmetric cryptography (ML-KEM for key exchange, ML-DSA for signatures). The symmetric side (AES, protecting the actual data) largely stays in place; there is only a discussion about key length, which you will see in the next lesson.
Why both, and not just one
Using only asymmetric cryptography (for example encrypting a whole file directly with RSA) is technically possible but not done in practice, because asymmetric operations are much slower than symmetric ones (big-number arithmetic, elliptic curve computations); for large volumes the difference can become seconds versus minutes. Using only symmetric cryptography is not possible either, because it does not solve key sharing: how would you agree on a shared secret key with a server you have never met, over the internet, and stop someone from stealing it in between? These two constraints (asymmetric is slow but solves key distribution, symmetric is fast but has the key distribution problem) together produce the “hybrid” approach: asymmetric for key distribution and authentication, symmetric for the actual data. This is not specific to TLS; almost every modern secure communication protocol, including SSH, S/MIME and VPN protocols (IKEv2/IPsec), follows the same pattern, and in M8 you will see how the PQC transition looks different in each of them.