Path: blob/main/foundations/04-number-theory-rsa/connect/rsa-tls-certificates.ipynb
483 views
Connect: RSA in TLS Certificates
Module 04 | Real-World Connections
Trace how RSA from Module 04 authenticates web servers in TLS.
Introduction
When you visit an HTTPS website, your browser verifies the server's identity before exchanging any sensitive data. This verification relies on digital certificates signed with RSA.
Every concept from Module 04 is at work in this process:
Prime generation (Notebook 04e) creates the CA's key pair
Modular exponentiation (Notebook 04f) performs signing and verification
Euler's theorem (Notebook 04c) guarantees correctness
The extended Euclidean algorithm (Notebook 04b) computes the private key
Let's trace exactly how this works.
The Certificate Chain
TLS uses a chain of trust:
Root CA (Certificate Authority): A trusted entity whose public key is pre-installed in your browser. Examples: DigiCert, Let's Encrypt, GlobalSign.
Intermediate CA: Signed by the root CA. The root CA delegates signing authority.
Server certificate: Signed by an intermediate CA. Contains the server's public key and domain name.
Your browser verifies: Root CA signature on Intermediate CA, then Intermediate CA signature on Server Certificate. Each signature is RSA (or ECDSA).
Let's build a toy version of this chain.
RSA Signatures: Signing and Verification
An RSA signature works as follows:
Signing (by the CA, using its private key ):
Compute a hash of the data:
Compute the signature:
Verification (by the browser, using the CA's public key ):
Compute the hash of the data:
Recover the hash from the signature:
Check: ?
This works because by Euler's theorem (Notebook 04c).
Step-by-Step: Building the Certificate Chain
Let's simulate the full certificate chain:
Root CA signs the Intermediate CA's certificate
Intermediate CA signs the server's certificate
Browser verifies the entire chain
PKCS#1 v1.5 Signature Format
In practice, RSA signatures don't just sign the raw hash. The PKCS#1 v1.5 standard specifies a padding format:
where DigestInfo is an ASN.1 structure that identifies the hash algorithm (SHA-256, etc.).
The padded message is then signed with RSA: .
This padding serves two purposes:
Unambiguity: the verifier knows which hash algorithm was used
Security: prevents certain forgery attacks on raw RSA signatures
Concept Map: Module 04 in TLS
| Module 04 Concept | TLS Application |
|---|---|
| Prime generation (04e) | CA generates RSA key pair for signing |
| Extended Euclidean algorithm (04b) | Computes during key generation |
| Modular exponentiation (04f) | Signing () and verification () |
| Euler's theorem (04c) | Guarantees |
| CRT (04d) | RSA-CRT optimization for fast signing on the server |
| GCD / coprimality (04a) | Choosing coprime to |
Every browser tab running HTTPS executes the number theory from Module 04.
Summary
| Concept | Key idea |
|---|---|
| Certificate chain | TLS uses a chain of trust: Root CA signs Intermediate CA, which signs the server certificate. Your browser walks the chain to verify the server's identity |
| RSA signatures | Signing computes (private key). Verification checks (public key). Euler's theorem guarantees correctness |
| Certificate forgery | Without the private key , forging a signature requires computing -th roots modulo , which is equivalent to factoring |
| PKCS#1 v1.5 padding | Signatures use a standardized padding format that identifies the hash algorithm and prevents certain forgery attacks |
| Module 04 in every browser tab | Prime generation, extended GCD, modular exponentiation, Euler's theorem, and CRT all run behind the scenes whenever you visit an HTTPS site |
The number theory from Module 04 runs billions of times per day across the internet.
Back to Module 04: Number Theory and RSA