Week 10 — Certificates and Cryptographic Methods¶

Click inside the slides and use the arrow keys; use the button at the bottom right of the slides or the link above for full screen.

# WSL / Linux / Git Bash
cd week-10/01-pki-zincir
sh demo.sh            # kök CA → ara CA → sunucu sertifikası üretir ve zinciri doğrular

cd ../02-imza-dogrulama
sh demo.sh            # Ed25519 ile imzala → doğrula → tek bayt kurcala → doğrulama reddetsin

openssl version
mkdir C:\Courses\h10; cd C:\Courses\h10

sudo apt install -y openssl softhsm2 opensc
openssl version
mkdir -p ~/h10 && cd ~/h10

0. Basic concepts (from scratch)¶

This section prepares you for the week. It first briefly recalls the earlier topics this week builds on; it then defines each of this week's concepts in one sentence and links it to the section where it is explained in full.

What we bring from earlier weeks¶

• Symmetric and asymmetric encryption — symmetric encryption runs fast with a single key shared by both parties; asymmetric encryption uses a public/private key pair, which makes key distribution easy but is slow (Week 3, §2.2). This week we go deeper into the asymmetric side's mathematics (RSA, ECC — §4) and the symmetric side's correct choice of mode and padding (§2).
• AEAD — authenticated encryption gives confidentiality and integrity together, in a single call, by producing a tag that also proves the data has not changed (Week 3, §2.1). This week we show why the mode inside AEAD (GCM) and the alternatives you should stay away from (ECB, CBC) give such different security (§2).
• Digest (hash), MAC, and digital signature — a digest is a one-way fingerprint computed from data; a MAC proves a message has not changed using a shared key, and a digital signature does the same with a public/private key pair (Week 3, §2.4). This week we cover HMAC's internal construction and the correct order for combining it with encryption (§3), and the practical pitfalls of signature verification (§5).
• Forward secrecy — deleting a session's derived key right after use, so that even if today's key leaks, past sessions cannot be decrypted (Week 3, §7.1). This week we build the Diffie–Hellman key exchange and its authentication — the mechanism underneath forward secrecy — from scratch (§6).
• TLS certificate validation — the client checking a server certificate's chain, validity dates, intended usage, and name (Week 3, §9.2). This week we build the PKI, X.509, and revocation (CRL/OCSP) machinery this validation rests on, from the ground up (§7–10).

This week's concept map¶

How do the concepts connect?¶

The terms above are not a random list; each one sits on top of the previous ones. The table below shows the relationship "to understand this, I first need to know that" — if you forget a term, go back to the "prerequisite" column in the table.

The direction in which this table is read matters: to understand the term at the start of a row, you must first know the term in the "prerequisite" column. For example, before reading the "certificate revocation" (CRL/OCSP) section, the concepts of "certificate" and "CA" need to already be settled; otherwise the question "why does the CA sign the revocation list?" is left hanging.

1. The map of cryptography and algorithm selection¶

We ended Week 9 with a warning: obfuscating code does not store a key, it only makes the surroundings harder to work with (Week 9, §3). This week we move on to the actual fix — instead of hiding keys, we protect them for real with the right algorithm choice, the right protocol, and, where needed, hardware-backed storage (PKI, HSM). In Week 3 we used cryptography as a tool to protect data in transit, at rest, and in use (Week 3, §1); this week we look inside those same tools: which algorithm does which job, why some were abandoned, how to choose, and how a certificate authority (CA) fits into this structure. The book's Chapters 4–8 and 10–11 cover these topics in more than 55 recipes; since most of the algorithms have changed since 2003, we give each one its current equivalent.

Five basic jobs, five tool families¶

Key length: security level¶

The key lengths of different algorithms cannot be compared directly. NIST SP 800-57 compares them at an equivalent security level (in bits):

Today, the floor for a new design is the 128-bit security level. This means 3072 bits for RSA, 256 bits for elliptic curve; 2048-bit RSA is not considered sufficient for new use after 2030 in NIST's transition timeline. The table's most important lesson is that elliptic curves provide the same security with much shorter keys; that is why they are preferred on mobile and embedded systems.

The weakest-link rule¶

A system uses more than one cryptographic layer: key exchange with one algorithm, data encryption with another. The system's security level equals the lowest of these layers — not the strongest. If you transport a key with RSA-2048 and encrypt the data with AES-256, the attacker doesn't try to break 256-bit AES; they target the ≈112-bit RSA layer. So evaluate the layers together, by the lowest level, not one at a time.

One rule: don't write your own crypto — or your own protocol¶

Even if every algorithm is correct, combining them (choosing what order to encrypt and MAC in, where to get the nonce from, how to separate the keys) requires a separate kind of expertise. All of this week's examples will show that almost all real-world mistakes are in the combination, not the algorithm. Wherever possible, use ready-made, proven constructions (TLS 1.3, AEAD, HPKE, Noise).

Worked example: how big is the difference between "128 bit" and "112 bit"?¶

The bit counts in the table can stay abstract; let's make them concrete. A security level of "n bits" means the attacker needs, on average, 2ⁿ⁻¹ attempted operations (2ⁿ is used as the upper bound). The difference between RSA-2048 (112 bit) and AES-128 (128 bit) is far larger than it looks:

2^112 ≈ 5,19 × 10^33   (RSA-2048's equivalent difficulty)
2^128 ≈ 3,40 × 10^38   (AES-128's key space)
2^128 / 2^112 = 2^16 = 65.536   → breaking AES-128 is 65.536 TIMES harder than breaking RSA-2048 at "equivalent" difficulty

Let's convert this into time. Let's take, as an optimistic upper bound, 10¹⁸ (quintillion; exascale supercomputer) operations per second for today's fastest supercomputers — in real attacks this number is much lower, because breaking a cipher is not a single arithmetic operation but a far more costly one. Still, let's calculate with the upper bound:

2^112 operations ÷ 10^18 operations/second ≈ 1,6 × 10^8 years  (≈ 165 million years)
Comparison: recorded human history ≈ 5.000 years → 165 million years is ~33.000 times that
2^128 operations ÷ 10^18 operations/second ≈ 1,08 × 10^13 years
Comparison: the age of the universe ≈ 1,38 × 10^10 years → 2^128 takes ~780 times the age of the universe

The lesson to draw has two parts. First, even 112 bits cannot practically be brute-forced today; the reason RSA-2048 is considered "insufficient" for use after 2030 is not brute force, but (a) hardware getting cheaper over time, (b) the need to protect data that must be kept for a long time with a margin against future attacks, and © the fact that quantum computers will be able to break RSA far faster than brute force (see Section 12). Second, the seemingly small difference between 112 bits and 128 bits (16 bits) cuts the attacker's work down to one in 65,536 — you must read bit counts exponentially, not linearly.

In Week 3 we only saw the "which tool do I use when" part of this map (AEAD, the hybrid scheme, random numbers). This week we see why the same map is drawn this way — which mathematical problem gives which security, why each algorithm was abandoned. The next two sections look inside the symmetric tools (mode, padding, MAC); Sections 4–6 look inside the asymmetric tools (RSA, ECC, DH); Sections 7–10 will look at how these come together in PKI.

2. Block cipher modes and padding (Recipe 5.4, 5.11)¶

AES is a block cipher: it turns exactly a 16-byte block into another 16-byte block. To encrypt a longer message you need a mode of operation that chains the blocks together. The choice of mode is as important as the choice of algorithm; recall the ECB penguin from Week 3.

Padding and the padding oracle¶

ECB and CBC require the message length to be a multiple of the block size; the missing part is filled in with padding. The most common padding is PKCS#7: if the number of missing bytes is n, n bytes each with the value n are appended (e.g., if 3 bytes are missing, 03 03 03). The decrypting party reads the last byte and drops that many bytes; but first it checks whether the padding is valid.

This is where the problem begins: if a decryption failure is distinguishable as "invalid padding" versus "invalid MAC" (a different error message, a different response time), an attacker can change bytes of the ciphertext and, by observing the server's reaction, decrypt the message byte by byte. This is called the padding oracle attack; it was described in 2002, and it kept reappearing in the following years in web frameworks and in TLS (POODLE, Lucky Thirteen).

Defences:

1. Use AEAD (GCM, ChaCha20-Poly1305): there is no padding; if the tag doesn't match, nothing is decrypted.
2. If CBC is mandatory, encrypt first, then MAC (next section) and verify the MAC before checking the padding.
3. Return all decryption errors as a single, identical error, in the same amount of time.

Worked example: tracing PKCS#7 padding by hand¶

Let's not leave the rule "if 3 bytes are missing, 03 03 03 is appended" abstract; let's trace it step by step with a real OpenSSL run. Let's encrypt the 13-byte text "MERHABA DUNYA" with AES-128-CBC using a fixed 16-byte key and an IV that counts up from zero (only for this example; in a real system the IV is generated randomly for every message):

K=00112233445566778899aabbccddeeff   # 16 bytes (32 hex characters) — fixed only for this demonstration
IV=000102030405060708090a0b0c0d0e0f  # 16 bytes — fixed only for this demonstration
printf 'MERHABA DUNYA' | openssl enc -aes-128-cbc -K "$K" -iv "$IV" -out cikti.bin
xxd -p cikti.bin

Output (the actually produced value):

4b354371f98acde5bed95d59a8135538

The input was 13 bytes; AES's block size is 16 bytes; the output is also exactly 16 bytes (32 hex characters) — so a 3-byte padding was added. To see the padding's content, let's decrypt with -nopad (we would normally never do this; here only for teaching purposes):

openssl enc -d -aes-128-cbc -K "$K" -iv "$IV" -in cikti.bin -nopad | xxd

00000000: 4d45 5248 4142 4120 4455 4e59 4103 0303  MERHABA DUNYA...

The last three bytes are 03 03 03 — exactly as the PKCS#7 rule says: as many bytes as the missing count (16 − 13 = 3) were added, each with that value. A normal openssl enc -d (without the no-padding flag) automatically reads and drops these three bytes and returns exactly "MERHABA DUNYA" to you — verify this too:

openssl enc -d -aes-128-cbc -K "$K" -iv "$IV" -in cikti.bin

MERHABA DUNYA

The padding oracle attack kicks in exactly at this point: the attacker changes the last bytes of the ciphertext and sends it to the server; if the server returns "invalid padding" (e.g., the last byte is 07 but the preceding 7 bytes are not 07) and "padding valid but MAC invalid" as different errors, the attacker can distinguish these two cases and reconstruct the plaintext byte by byte — without ever needing the key.

Worked example: seeing why ECB leaks patterns¶

In ECB, every 16-byte block is encrypted independently; the same plaintext block always produces the same ciphertext block. Let's encrypt a plaintext that repeats over 48 bytes ("AAAAAAAAAAAAAAAA" three times) with AES-128-ECB:

K2=$(openssl rand -hex 16)
printf 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' | head -c 48 > duz.txt   # 48 bytes = 3 blocks, all the same
openssl enc -aes-128-ecb -K "$K2" -in duz.txt -out cikti_ecb.bin -nopad
xxd cikti_ecb.bin

The output of an example run (since the key is random, you will see different byte values, but the pattern will stay the same):

00000000: f5cf 4879 d8fe 9c90 1975 2de6 eb9f 59a1  ..Hy.....u-...Y.
00000010: f5cf 4879 d8fe 9c90 1975 2de6 eb9f 59a1  ..Hy.....u-...Y.
00000020: f5cf 4879 d8fe 9c90 1975 2de6 eb9f 59a1  ..Hy.....u-...Y.

All three blocks are identical. Even an observer who doesn't know the key learns the information "these three blocks contain the same plaintext" — which is often a leak in its own right (e.g., an image's background, a form's fixed fields, a repeating record structure). If you repeat the same experiment with AES-128-CBC (with a random IV), all three blocks come out different; because each block is chained by being XORed with the previous one.

In Week 2's threat modelling, "integrity" was an asset-protection goal; this section made concrete why that goal cannot be achieved by encryption alone. The next section covers the tool that correctly provides integrity — MAC/HMAC — and the right order for combining it.

3. MAC, HMAC, and combining integrity with encryption (Recipe 6.4, 6.10, 6.18, 6.21)¶

How does HMAC work?¶

Encrypt-then-MAC: because the receiver never decrypts invalid ciphertext, the "error leak" that a padding oracle needs never arises. AES-GCM does these two steps in a single operation.

A MAC (message authentication code) produces a short tag from a secret key and a message; someone who doesn't know the key cannot produce a valid tag. HMAC is the standard way of building a MAC from a hash function (SHA-256) (RFC 2104):

HMAC(K, m) = H( (K ⊕ opad) ‖ H( (K ⊕ ipad) ‖ m ) )

The two nested digests remove the length-extension weakness of the plain H(K ‖ m) construction: in Merkle–Damgård-structured digests like SHA-256, if H(K ‖ m) is known, H(K ‖ m ‖ extra) can be computed without knowing the key. So don't derive your own MAC from a digest; use HMAC (the warning in Recipe 6.19).

printf 'tutar=100;alici=TR00' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$(openssl rand -hex 32)

Three ways to combine encryption with a MAC¶

AEAD modes make this choice correctly on your behalf. If you must do your own combination (Recipe 6.18): use two separate keys (one for encryption, one for the MAC; both can be derived from a single secret with HKDF), follow the encrypt-then-MAC order, include the IV and context information in the MAC as well, and make the comparison constant-time.

Replay: a valid but old message¶

A MAC proves that a message has not been changed, but not that it is new. An attacker can record a valid "send 100 TL" message and resend it ten times; the MAC is valid every time. The defences the book describes in Recipe 6.21:

Worked example: computing HMAC by hand and seeing the avalanche effect¶

Without leaving the rules abstract, let's trace a real HMAC-SHA-256 computation end to end. Let's use a fixed (only for this example) 32-byte key and compute the HMAC of a payment instruction:

ANAHTAR=0000000000000000000000000000000000000000000000000000000000000001   # 32 bytes, fixed only for this demonstration
printf 'tutar=100;alici=TR00' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$ANAHTAR

SHA2-256(stdin)= a08fb1159871e3b8110dedf3e3524cab7bea06f4795f2119394e11c42ac5f9a1

Now let the attacker change the amount from 100 to 900; with the real key, the original message's HMAC changes as follows:

printf 'tutar=900;alici=TR00' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$ANAHTAR

SHA2-256(stdin)= 8a786eacbef7863d44533b9ebcbcf288e5136204080258e838e283f1f91a46be

A single-character change (1→9) produced completely different 32 bytes for the tag — this is a good hash function's "avalanche effect": a single-bit change in the input changes roughly half of the output. Since the attacker doesn't know the key, they cannot change the message and produce a valid new tag; the receiver compares the tags and catches the mismatch.

Constant-time comparison: why memcmp is not enough¶

On the receiving side, HMAC verification requires comparing the computed tag with the tag that arrived. An ordinary memcmp(a, b, 32) compares bytes left to right and stops at the first differing byte; this means the function's running time varies depending on how many bytes matched. An attacker who can make enough attempts over a network can guess the correct tag byte by byte from microsecond differences in response times (a timing attack).

/* WRONG: an early exit creates a timing difference */
if (memcmp(hesaplanan, gelen, 32) == 0) { /* accept */ }

/* CORRECT: constant-time, always walks through all 32 bytes */
if (CRYPTO_memcmp(hesaplanan, gelen, 32) == 0) { /* accept */ }   /* OpenSSL */
/* or: sodium_memcmp (libsodium), hmac.compare_digest (Python) */

In Week 3 we introduced AEAD as "the tool that gives confidentiality + integrity in a single package"; this section showed the correct order and the correct comparison for when you are forced to provide integrity separately (an old protocol where you can't use AEAD, a hardware constraint, etc.). The next section moves on to the asymmetric tools that give what a MAC cannot — non-repudiation.

4. Asymmetric cryptography: RSA and elliptic curves (Recipe 7.1–7.3)¶

Symmetric cryptography's only difficulty is that the two parties must share the same key in advance. In asymmetric (public-key) cryptography, each party has a key pair: a public key given to everyone, and a private key known only to its owner. What is encrypted with the public key can only be decrypted with the private key; what is signed with the private key can be verified by everyone with the public key.

Asymmetric operations are hundreds, thousands of times slower than symmetric ones. This is why asymmetric cryptography is used for only two jobs (Recipe 7.1): carrying or agreeing on a short symmetric key and signing. The data itself is always protected with a symmetric cipher (the hybrid scheme from Week 3).

RSA: with the right padding¶

RSA's mathematics in its plain form ("textbook RSA") is insecure: the same message always gives the same ciphertext, and its mathematical structure is open to attacks. Secure use depends on the correct padding scheme:

The book's "raw" RSA operations in Recipes 7.10–7.13 are there to help you understand how unpadded RSA works; they are not used in production. The warning in Recipe 7.14 still matters, though: combining sign-and-encrypt needs care; if the signature is not bound to the recipient and context of the encrypted content, the recipient can re-encrypt the signed message and forward it to someone else.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa_ozel.pem
openssl pkey -in rsa_ozel.pem -pubout -out rsa_acik.pem

# Encrypt a short session key with OAEP (SHA-256)
openssl rand -out oturum.key 32
openssl pkeyutl -encrypt -pubin -inkey rsa_acik.pem -in oturum.key -out oturum.enc \
    -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256

# Sign and verify with PSS
openssl dgst -sha256 -sign rsa_ozel.pem -sigopt rsa_padding_mode:pss -out belge.sig belge.txt
openssl dgst -sha256 -verify rsa_acik.pem -sigopt rsa_padding_mode:pss -signature belge.sig belge.txt

Elliptic curves: the same security, a shorter key¶

Elliptic-curve cryptography (ECC) provides the security level of 3072-bit RSA with a 256-bit key; its operations are faster, and its keys and signatures are much shorter.

openssl genpkey -algorithm ED25519 -out ed_ozel.pem
openssl pkey -in ed_ozel.pem -pubout -out ed_acik.pem
openssl pkeyutl -sign   -inkey ed_ozel.pem -rawin -in belge.txt -out belge.ed.sig
openssl pkeyutl -verify -pubin -inkey ed_acik.pem -rawin -in belge.txt -sigfile belge.ed.sig

Worked example: measuring RSA-3072 against Ed25519¶

Let's confirm the sentence "ECC gives the same security with a smaller key" with real bytes. Both are at ~128-bit security level (see the table in Section 1):

wc -c rsa_acik.pem ed_acik.pem
openssl dgst -sha256 -sign rsa_ozel.pem -sigopt rsa_padding_mode:pss -out belge.rsa.sig belge.txt
openssl pkeyutl -sign -inkey ed_ozel.pem -rawin -in belge.txt -out belge.ed.sig
wc -c belge.rsa.sig belge.ed.sig

  636 rsa_acik.pem
  116 ed_acik.pem
  384 belge.rsa.sig
   64 belge.ed.sig

The public key file (PEM, Base64-encoded) is 636 bytes for RSA, 116 bytes for Ed25519 — roughly 5.5 times smaller. The signature is 384 bytes for RSA (3072 bits = 384 bytes; an RSA signature is exactly the size of the modulus), 64 bytes for Ed25519 — 6 times smaller. When you consider the data an IoT device sends on every handshake, the number of certificates an embedded system stores in flash, or the number of signatures carried by every transaction on a blockchain, this difference accumulates and grows; this is why ECC is the default in mobile/embedded systems and in new protocols (TLS 1.3, SSH, Signal).

Worked example: why is OAEP's randomness necessary?¶

In Section 2 we saw that ECB produces the same ciphertext for the same plaintext block, and that this is a pattern leak. "Textbook RSA" (raw, unpadded) carries the same disease: the same message always produces the same ciphertext. OAEP fixes this by mixing a random value into the message before encryption. Let's encrypt the same message twice with OAEP:

echo MERHABA > kisa.txt
openssl pkeyutl -encrypt -pubin -inkey rsa_acik.pem -in kisa.txt -out c1.bin \
    -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256
openssl pkeyutl -encrypt -pubin -inkey rsa_acik.pem -in kisa.txt -out c2.bin \
    -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256
cmp c1.bin c2.bin && echo "AYNI" || echo "FARKLI"

c1.bin c2.bin differ: char 1, line 1
FARKLI

Same public key, same plaintext, but different ciphertext — because OAEP uses a new random value on every encryption (the RSA counterpart of Section 1's "random numbers are the invisible foundation of cryptography" principle). If you run the same experiment with unpadded ("raw") RSA, the two outputs come out byte-for-byte identical; mathematically, c = m^e mod n is a deterministic operation. This is why raw RSA is never used directly for encryption.

In Week 3 we used asymmetric cryptography (RSA or ECDHE back then) as a black box in TLS's key setup. This section opened up that black box: which padding, which curve, which size. The next section goes deeper into the signature leg of these tools; then in Section 6 we move on to the key exchange leg.

5. Digital signature: creation, verification, and where it's used¶

A digital signature proves that a message (1) was created by the owner of a specific private key, and (2) has not been altered afterward. Unlike a MAC, verification is done with the public key: anyone can verify, but only the owner of the private key can sign. This is why a signature provides non-repudiation (the R in STRIDE), a MAC does not.

Where are signatures used?¶

Verifying a signature in code: OpenSSL EVP¶

#include <openssl/evp.h>
#include <openssl/pem.h>

/* 1: valid, 0: invalid, -1: error. Called BEFORE running the update package. */
int imza_dogrula(EVP_PKEY *acik, const unsigned char *veri, size_t n,
                 const unsigned char *imza, size_t imza_n)
{
    EVP_MD_CTX *ctx = EVP_MD_CTX_new();
    int sonuc = -1;
    if (ctx == NULL) return -1;
    if (EVP_DigestVerifyInit(ctx, NULL, NULL, NULL, acik) == 1)   /* Ed25519: digest is NULL */
        sonuc = EVP_DigestVerify(ctx, imza, imza_n, veri, n);      /* 1 or 0 */
    EVP_MD_CTX_free(ctx);
    return sonuc == 1 ? 1 : (sonuc == 0 ? 0 : -1);
}

Worked example: tracing signature verification in three cases from the command line¶

You can see the logic of the C code above with openssl pkeyutl -verify too, without needing to compile — the CLI produces the same three outcomes (valid / invalid / error):

openssl pkeyutl -verify -pubin -inkey ed_acik.pem -rawin -in belge.txt -sigfile belge.ed.sig
echo "cikis kodu: $?"

Signature Verified Successfully
cikis kodu: 0

echo "MERHABA DEGISTI" > belge2.txt
openssl pkeyutl -verify -pubin -inkey ed_acik.pem -rawin -in belge2.txt -sigfile belge.ed.sig
echo "cikis kodu: $?"

Signature Verification Failure
cikis kodu: 1

The moment a single byte of the document changed, verification failed and the exit code went from 0 to 1 — if your update mechanism doesn't check this code (or if the C code interprets EVP_DigestVerify's return with if (sonuc)), you have made a tampered package executable.

Rollback: the signature is valid but the content is old¶

Let's make the "scope of the signature" trap concrete. Suppose an application update server signs each version separately:

After the server publishes v2.0, v1.0's signature is not revoked — signatures do not have a revocation mechanism like CRL/OCSP (the mechanism we will see for certificates in Section 10). If an attacker who has obtained the v1.0 package presents it along with imza_v1 to the client, the client only asks "is the signature valid?", gets the answer yes, and installs the vulnerable version. This is why the signed data must not be only the file's content, but the version number + target product name, and the client must additionally enforce, on its own, the rule "do not accept a version older than the highest one I have seen" — the signature does not do this for you.

In Week 1's "Vault" example we saw that accepting an update package without a signature leads to the T6 threat; this section showed that even the existence of a signature alone is not enough — its scope must also be designed correctly. The next section covers how we use signatures and asymmetric cryptography in key exchange — and what goes wrong if we don't.

6. Key exchange: Diffie–Hellman and man-in-the-middle (Recipe 8.16–8.18)¶

Diffie–Hellman (DH) lets two parties agree on a shared secret over an insecure channel, with no previously shared secret at all. Each party picks a private value and sends the public value derived from it; both parties compute the same shared secret from the other party's public value and their own private value. An eavesdropper sees the public values but cannot compute the shared secret. Today's form of this is ECDH over an elliptic curve (X25519).

The weakness of unauthenticated DH: man-in-the-middle¶

DH does not say who you agreed with. An attacker in the middle of the channel performs DH separately with each of the two parties:

Both parties think "I have a secure channel"; in reality every message passes through the attacker's hands.

The fix: authenticated key exchange¶

The public values are signed with a key whose identity is known in advance (the current version of Recipe 8.18's "DH and DSA together" idea: ECDHE + Ed25519/ECDSA/RSA-PSS). In TLS 1.3, the server signs the handshake digest — which also includes the ephemeral ECDHE public value — with the private key in its certificate (CertificateVerify); the client verifies the certificate by chain and by name (Week 3). This way:

• Identity: The signature proves that whoever sent the public value really is the certificate's owner.
• Forward secrecy: DH values are freshly generated and discarded for every session; even if the long-lived signing key is stolen later, past sessions' keys cannot be computed (Week 3).

Worked example: two parties reaching the same secret with X25519¶

Let's confirm Diffie–Hellman's sentence "two parties reach the same shared value, without a previously shared secret" with real keys. Alice and Bob each independently generate an X25519 key pair and exchange only their public keys:

openssl genpkey -algorithm X25519 -out alice.key
openssl genpkey -algorithm X25519 -out bob.key
openssl pkey -in alice.key -pubout -out alice.pub
openssl pkey -in bob.key -pubout -out bob.pub

# Alice: her own private key + Bob's public key
openssl pkeyutl -derive -inkey alice.key -peerkey bob.pub -out alice_sir.bin
# Bob: his own private key + Alice's public key
openssl pkeyutl -derive -inkey bob.key -peerkey alice.pub -out bob_sir.bin

xxd -p alice_sir.bin
xxd -p bob_sir.bin
cmp alice_sir.bin bob_sir.bin && echo "AYNI" || echo "FARKLI"

8c53744a000c1a6ffc2183a0c134c2cf8167110314e8a06dd3d453080bbc1376
8c53744a000c1a6ffc2183a0c134c2cf8167110314e8a06dd3d453080bbc1376
AYNI

The two parties, without ever knowing each other's private key, reached the same 32-byte shared secret, passing only public keys over the network. This shared secret is not used directly for data encryption; it is passed through a KDF (HKDF, the key-derivation topic from Week 3) and session keys are derived from it. A third-party eavesdropper sees only alice.pub and bob.pub; computing the shared secret from these (without solving the elliptic-curve discrete logarithm problem) is not possible.

Worked example: how many steps does a man-in-the-middle take to set up?¶

Man-in-the-middle against unauthenticated DH requires two separate DH agreements — the attacker's computational load is no different from the victims', just twice the operations:

1. The attacker (M) connects to Alice and sends their own public value as pub_M1; Alice thinks this is Bob's public value.
2. M connects to Bob and sends pub_M2; Bob thinks this is Alice's public value.
3. M computes sir_A = DH(özel_M1, pub_Alice) with Alice and sir_B = DH(özel_M2, pub_Bob) with Bob — obtaining two different shared secrets.
4. Alice sends an encrypted message with sir_A to "Bob" (actually M); M decrypts it, reads it, re-encrypts it with sir_B, and forwards it to the real Bob. Both parties believe the secret they computed is shared with the correct other party.

The attacker's extra cost is only twice the X25519 operations (on the order of microseconds) — without authentication, this attack is essentially free computationally. This is why unsigned DH is never used alone in any modern protocol such as TLS 1.3.

In Week 3's TLS 1.3 handshake we asked "what would happen if someone in the middle could swap the keys"; this section answered that question with concrete steps. The next three sections (7–9) build, from scratch, the identity infrastructure — PKI — that signed DH rests on.

7. Public key infrastructure (PKI): who trusts whom? (Recipe 10.1)¶

The previous section showed that public keys need to be bound to an identity through a signature. But this raises a question: how do we know that a server's public key really belongs to that server? Public key infrastructure (PKI) is the set of rules, roles, and documents that answers this question through trusted third parties.

Components¶

Why an intermediate CA? If the root CA's private key is compromised, the entire chain becomes untrusted, and removing the root from every trust store in the world takes years. This is why the root key sits in an HSM, offline, in a physically protected location, and is used only to sign intermediate CA certificates, in controlled meetings called a key ceremony. The intermediate CA does the day-to-day work; if it is compromised, only that intermediate CA is revoked.

Validating a certificate: four questions (Recipe 10.4)¶

Before a client accepts a certificate, it asks the following:

1. Chain: Starting from the leaf certificate, is every certificate's signature verified with the one above it's public key, and does the chain reach a root in the trust store?
2. Validity: Are we within the validity dates of every certificate in the chain?
3. Usage: Was this certificate issued for this job? (The key usage and extended key usage fields; the CA:TRUE basic constraint on an intermediate CA.)
4. Name and revocation: Is the certificate for this server (SAN)? Has it been revoked?

In Week 3 we saw how the first and fourth questions are asked in code (SSL_CTX_set_verify, SSL_set1_host). In this section we build the same chain ourselves.

Worked example: asking the "four questions" from the command line¶

Let's see how a client asks the "four questions" concretely, using the root → intermediate → server chain we will build in Section 9 (if you don't have these three files yet, run Section 9 first; here we are only reading the same files from different angles).

Question 1 — Chain: every certificate's issuer field must match, exactly, the subject field of the one above it:

openssl x509 -in sunucu.crt -noout -issuer -subject
openssl x509 -in ara.crt    -noout -issuer -subject
openssl x509 -in kok.crt    -noout -issuer -subject

issuer=CN=CEN429 Lab Ara CA     subject=CN=localhost
issuer=CN=CEN429 Lab Kok CA     subject=CN=CEN429 Lab Ara CA
issuer=CN=CEN429 Lab Kok CA     subject=CN=CEN429 Lab Kok CA

The chain reads: sunucu's issuer = ara's subject; ara's issuer = kok's subject; kok's issuer is itself (the root signs itself — which is why the chain stops here).

Question 2 — Validity:

openssl x509 -in sunucu.crt -noout -dates
openssl x509 -in sunucu.crt -noout -checkend 0

notBefore=Sep 23 06:01:46 2026 GMT
notAfter=Dec 22 06:01:46 2026 GMT
Certificate will not expire

-checkend 0 asks "will this expire within 0 seconds from now?"; TLS clients perform this check automatically on every connection.

Question 3 — Usage:

openssl x509 -in sunucu.crt -noout -ext basicConstraints,keyUsage,extendedKeyUsage
openssl x509 -in ara.crt    -noout -ext basicConstraints,keyUsage

X509v3 Basic Constraints: CA:FALSE
X509v3 Key Usage: critical / Digital Signature
X509v3 Extended Key Usage: TLS Web Server Authentication
---
X509v3 Basic Constraints: critical / CA:TRUE, pathlen:0
X509v3 Key Usage: critical / Certificate Sign, CRL Sign

sunucu.crt having CA:FALSE guarantees that this certificate cannot sign another certificate — even if an attacker obtains this certificate's private key, they cannot use it to produce and sign a new certificate. ara.crt is the opposite: CA:TRUE and pathlen:0 (there can be no other intermediate CA below it, it can only sign leaf certificates).

Question 4 — Name: the SAN field is already visible above via -ext subjectAltName (DNS:localhost, IP Address:127.0.0.1); the client compares the name it connected to against this list (covered in detail in Section 8).

A client library (OpenSSL, Windows CryptoAPI, Java's X509TrustManager) asks these four questions on your behalf; disabling the verify functions (Week 3's SSL_CTX_set_verify) or swallowing errors means these four questions are never asked at all.

In the previous section we saw that signed DH proves "who I'm talking to" with a signature; this section explained how we trust whose signature that is (PKI, the CA hierarchy). The next two sections look at the document itself that carries this trust (the X.509 certificate) and at building it by hand.

8. The structure of an X.509 certificate¶

An X.509 v3 certificate consists of the signed part (TBSCertificate) and the CA's signature over that part:

Certificates are stored in binary DER encoding, or in PEM, its Base64-wrapped text form (Recipe 7.16, 7.17): files starting with -----BEGIN CERTIFICATE----- are PEM.

Worked example: reading a real certificate field by field¶

Let's read the openssl x509 -text output of the sunucu.crt we will generate in Section 9, matching it against every field in the table above (this is exactly the real output of the command openssl x509 -in sunucu.crt -noout -text):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            35:e2:f6:8d:d2:e3:90:f3:74:ff:16:a9:ec:5f:07:e9:21:69:76:e7
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=CEN429 Lab Ara CA
        Validity
            Not Before: Sep 23 06:01:46 2026 GMT
            Not After : Dec 22 06:01:46 2026 GMT
        Subject: CN=localhost
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:127.0.0.1
            X509v3 Subject Key Identifier:
                EA:59:FF:05:1B:BA:D2:ED:D3:B8:2D:CF:12:32:F6:52:27:CD:98:87
            X509v3 Authority Key Identifier:
                F5:BA:39:86:1F:A1:D0:79:C8:DA:83:7D:AE:2C:87:9D:56:45:CE:25
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:46:02:21:00:8e:a3:91:48:0a:d5:8a:9d:a7:ee:08:ae:27:...

Line by line: Version 3 shows we can use the extension fields (the X509v3 block). The Serial Number is unique among the certificates this CA has issued — when a certificate is revoked, this number is listed in the CRL (Section 10). The Issuer (CN=CEN429 Lab Ara CA) tells you who signed this certificate — this is where the answer to Section 7's "Question 1" lives. Validity is Section 7's "Question 2." The Subject (CN=localhost) is the identity the certificate claims to belong to — but you must check the SAN before trusting this claim (see above). Subject Public Key Info is the public key this certificate validates itself (a point on the 256-bit P-256 curve). Basic Constraints: CA:FALSE is the answer to Section 7's "Question 3": this certificate cannot sign another certificate. Subject Alternative Name is the answer to Section 7's "Question 4." Authority Key Identifier is the fingerprint of the public key of the CA that signed this certificate; the client uses it, while building the chain, to avoid the confusion of "a fake intermediate certificate with the same issuer name but signed with a different key." At the bottom, Signature Value is the signature produced over all these fields (the TBSCertificate) with the CA's private key — exactly the signing mechanism we learned in Section 5.

Worked example: how many bytes is a certificate?¶

openssl x509 -in sunucu.crt -outform DER | wc -c
wc -c sunucu.crt

The DER (binary) form is generally around 500–900 bytes (since curve-based keys are smaller than RSA); the PEM form is roughly 33% larger than this because of Base64 encoding (Base64 turns every 3 binary bytes into 4 text characters). In a TLS handshake, the certificate chain the server sends (leaf + intermediate) is the sum of these sizes; this is why a chain using RSA-3072 certificates can be many times larger than an ECC (P-256/Ed25519) chain — the reflection, in PKI, of Section 4's size comparison.

Section 7 explained the trust a certificate carries; this section showed in which bytes that trust is encoded. The next section switches to the CA's role and builds this document by hand.

9. Building a certificate chain with OpenSSL¶

The steps below build a three-layer chain in your own lab. All files are created in the working folder; never add the root certificate to any trust store.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out kok.key
openssl req -x509 -new -key kok.key -sha256 -days 3650 -out kok.crt \
  -subj "/CN=CEN429 Lab Kok CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ara.key
openssl req -new -key ara.key -out ara.csr -subj "/CN=CEN429 Lab Ara CA"
openssl x509 -req -in ara.csr -CA kok.crt -CAkey kok.key -CAcreateserial -days 1825 -sha256 \
  -out ara.crt -extfile <(printf "basicConstraints=critical,CA:TRUE,pathlen:0\nkeyUsage=critical,keyCertSign,cRLSign")

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out sunucu.key
openssl req -new -key sunucu.key -out sunucu.csr -subj "/CN=localhost"
openssl x509 -req -in sunucu.csr -CA ara.crt -CAkey ara.key -CAcreateserial -days 90 -sha256 \
  -out sunucu.crt -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=critical,digitalSignature\nextendedKeyUsage=serverAuth\nsubjectAltName=DNS:localhost,IP:127.0.0.1")

openssl verify -CAfile kok.crt -untrusted ara.crt sunucu.crt      # sunucu.crt: OK
openssl x509 -in sunucu.crt -noout -text | less                    # inspect the fields
openssl verify -CAfile kok.crt sunucu.crt                          # without the intermediate: ERROR (chain incomplete)

The last command producing an error is instructive: a client can only build the chain if the intermediate certificate is also presented. Servers sending only the leaf certificate and forgetting the intermediate is a configuration mistake commonly seen in the field.

Class activity: breaking the chain¶

Note the openssl verify output at every step:

1. Sign the server certificate with the root but leave the intermediate CA in the chain. What changes?
2. Produce the intermediate CA with CA:FALSE and sign the server certificate with it. What does validation say?
3. Produce a certificate that expires immediately with -days 0.
4. Set the SAN to DNS:baska.ornek and try it with openssl s_client -verify_hostname localhost.

Worked example: solving two scenarios of the class activity from start to finish¶

Let's solve the first two of the four scenarios above together; you will complete scenarios 3 and 4 yourself.

Scenario 1 — Signing the server certificate directly with the root (skipping the intermediate CA):

openssl x509 -req -in sunucu.csr -CA kok.crt -CAkey kok.key -CAcreateserial -days 90 -sha256 \
  -out sunucu_kok.crt -extfile sunucu.ext
openssl verify -CAfile kok.crt -untrusted ara.crt sunucu_kok.crt

sunucu_kok.crt: OK

This may be surprising: even though we also supplied ara.crt, validation passed, because OpenSSL could build the chain from sunucu_kok.crt directly to kok.crt; ara.crt was never used on this path, it just sat in the pool as an available candidate. The lesson here is operational, not cryptographic: mathematically, the root CA can directly sign any certificate it wants. But we must not do this, because if the root CA's private key sits on a system used every day (the "why an intermediate CA" explanation in Section 7), the risk of compromise increases and the whole chain collapses.

Scenario 2 — Producing the intermediate CA with CA:FALSE:

printf "basicConstraints=critical,CA:FALSE\nkeyUsage=critical,keyCertSign,cRLSign\n" > ara_yanlis.ext
openssl x509 -req -in ara.csr -CA kok.crt -CAkey kok.key -CAcreateserial -days 1825 -sha256 \
  -out ara_yanlis.crt -extfile ara_yanlis.ext

openssl x509 -req -in sunucu.csr -CA ara_yanlis.crt -CAkey ara.key -CAcreateserial -days 90 -sha256 \
  -out sunucu_yanlis.crt -extfile sunucu.ext

openssl verify -CAfile kok.crt -untrusted ara_yanlis.crt sunucu_yanlis.crt

CN=CEN429 Lab Ara CA
error 79 at 1 depth lookup: invalid CA certificate
error sunucu_yanlis.crt: verification failed

This time validation was rejected — because ara_yanlis.crt's basicConstraints is CA:FALSE, even though the mathematical signature is correct, OpenSSL sees that this certificate has no authority to sign another certificate and treats the chain as invalid at "depth 1" (the middle layer). This is proof that the Basic Constraints field from Section 8 is an extension that actually changes behaviour — not a fancy text field.

Compare Scenario 1 with Scenario 2: both build a "wrong" chain, but one (signing directly with the root) is cryptographically valid and only an operational mistake; the other (signing with CA:FALSE) is rejected at the protocol level. When an evaluator inspects your PKI setup, this is exactly the distinction they look for: "does the chain technically work" and "does the chain follow the design rules" are two separate questions.

10. Certificate revocation: CRL, OCSP, and stapling (Recipe 10.10–10.12)¶

If a certificate's private key is stolen, or the certificate was issued incorrectly, it must be revoked before its validity period expires. There are three ways for the client to learn this:

# producing a CRL with the intermediate CA requires 'openssl ca' configuration; then:
openssl ca -config ara.cnf -revoke sunucu.crt
openssl ca -config ara.cnf -gencrl -out ara.crl
openssl verify -crl_check -CAfile kok.crt -untrusted ara.crt -CRLfile ara.crl sunucu.crt   # "certificate revoked"

Worked example: revoking a certificate and validating it against a CRL (end to end)¶

Let's trace the full version of the "summary" commands above, actually run, step by step. First, the minimal database and configuration file that openssl ca needs is set up (this is a heavily scaled-down version of a real CA):

mkdir -p demoCA/newcerts
touch demoCA/index.txt          # the "ledger" where every issued/revoked certificate is recorded
echo 1000 > demoCA/crlnumber    # the next CRL's version number
echo 1000 > demoCA/serial       # the next certificate's serial number

[ ca ]
default_ca = ara_ca

[ ara_ca ]
dir              = demoCA
database         = $dir/index.txt
new_certs_dir    = $dir/newcerts
certificate      = ara.crt
private_key      = ara.key
serial           = $dir/serial
crlnumber        = $dir/crlnumber
default_md       = sha256
default_days     = 90
default_crl_days = 30
policy           = policy_any
email_in_dn      = no

[ policy_any ]
commonName = supplied

openssl ca -config ara.cnf -revoke sunucu.crt

Using configuration from ara.cnf
Adding Entry with serial number 35E2F68D...76E7 to DB for /CN=localhost
Revoking Certificate 35E2F68D...76E7.
Database updated

openssl ca -config ara.cnf -gencrl -out ara.crl
openssl verify -crl_check -CAfile kok.crt -untrusted ara.crt -CRLfile ara.crl sunucu.crt

CN=localhost
error 23 at 0 depth lookup: certificate revoked
error sunucu.crt: verification failed

Step by step, what happened: (1) -revoke recorded the certificate's serial number (Section 8's Serial Number field — here 35E2F68D...76E7) as "revoked" in the index.txt ledger; the certificate itself was not changed or deleted in any way — only a record was added. (2) -gencrl collected all the revocation records in this ledger and produced a list (ara.crl) signed with the intermediate CA's own private key — the CRL itself is also a signed document, protected against forgery by the same mechanism from Section 5. (3) With -crl_check, validation now checked not only the chain but also the CRL, saw that the serial number was on the list, and rejected it with the "certificate revoked" error — even though the certificate's validity date has not yet expired.

This is the complete solution to Exercise 6; repeat the same steps in your own lab and inspect the contents of index.txt (cat demoCA/index.txt) — every line carries a certificate's record (status, date, serial number, subject name).

Worked example: how big does a CRL get?¶

If a CA issues 10,000 certificates a year and 1% of them (100) are revoked, since every CRL entry carries ~40–60 bytes (serial number + revocation date + reason code), the CRL size is ~4–6 KB — that looks small. But for a large public CA (millions of certificates, hundreds of thousands of revocations), the CRL can reach tens of megabytes; every client downloading this periodically is not practical. OCSP solves this scaling problem by "asking a single question" instead of "downloading the entire list" — but then the privacy and availability trade-off above reappears.

In Section 9 we learned to build a chain; in this section we learned to invalidate one link in a chain. The next section covers how we protect the most valuable piece of this chain — the private keys themselves.

11. Storing the key in hardware: HSM, PKCS#11, and SoftHSM¶

A stolen private key destroys all of PKI's guarantees. This is why valuable keys (CA keys, payment keys, code signing keys) are generated inside hardware security modules (HSM) and never leave them. The application never sees the key; it tells the HSM "sign this with that key."

export SOFTHSM2_CONF=$PWD/softhsm2.conf
mkdir -p belirtecler && echo "directories.tokendir = $PWD/belirtecler" > softhsm2.conf
softhsm2-util --init-token --free --label "cen429" --pin 1234 --so-pin 5678
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --login --pin 1234 \
            --keypairgen --key-type EC:prime256v1 --label imza-anahtari
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --login --pin 1234 --list-objects

End to end: how is a signing request processed inside an HSM?¶

Let's make the sentence "the key never leaves" concrete. The PKCS#11 standard (OASIS Cryptoki v3) defines the following steps for an application to have an HSM sign something without ever sending or receiving a raw key byte:

1. Open a session: The application connects to a "slot" in the HSM with C_OpenSession.
2. Authenticate: The PIN is sent with C_Login; if the PIN is wrong, the HSM locks itself after a certain number of attempts (hardware-level protection against brute force — an easy safeguard to forget in software).
3. Find the key: The handle of a previously generated key object (a reference number inside the HSM, not the key itself) is obtained with C_FindObjectsInit / C_FindObjects.
4. Sign: The call C_SignInit + C_Sign(handle, data, …) sends the data to the HSM; the HSM processes the data with the key inside itself and returns only the signature. The private key's bytes never enter the application code's memory at any point.
5. Close the session: C_Logout / C_CloseSession.

CK_RV C_Sign(
    CK_SESSION_HANDLE hSession,   /* open session */
    CK_BYTE_PTR       pData,      /* data to be signed */
    CK_ULONG          ulDataLen,
    CK_BYTE_PTR       pSignature, /* output buffer filled by the HSM: only the signature, not the key */
    CK_ULONG_PTR      pulSignatureLen
);

Compare this flow with an ordinary OpenSSL call (EVP_DigestSign, Section 5): both interfaces carry the same idea ("give the data, get the signature"), but in OpenSSL the key (if read from a file) sits in process memory; in PKCS#11 the key never enters the application's address space. Moving Section 5's imza_dogrula function to an HSM only means routing the signing side to a C_Sign call — the verification side already only needs the public key, so it does not need the HSM.

Why is CKA_EXTRACTABLE the most critical attribute?¶

When a PKCS#11 key object is generated (C_GenerateKeyPair), the attributes CKA_EXTRACTABLE=false and CKA_SENSITIVE=true are given at key-generation time and cannot be changed afterward. These two flags prevent, at the hardware level, the HSM from ever giving out the key in plaintext, even if a function like C_WrapKey is called.

We will look again, in Week 11, at software-based security modules (structures like the Secure Enclave/TEE on mobile devices) through the PKCS#11 logic of this section; the principle you learned here — "work through a handle, never move the raw key" — is the foundation of that entire discussion. The next and final technical section looks at why the RSA/ECC we consider secure today needs to change in the future.

12. A look at post-quantum cryptography¶

A sufficiently large quantum computer can efficiently solve the mathematical problems RSA and elliptic curves rest on (factoring, discrete logarithm). Such a computer does not exist yet; but the idea that encrypted traffic recorded today could be decrypted years from now ("harvest now, decrypt later") puts the transition on the agenda starting today.

For this course's project, the practical outcome is a single sentence: crypto agility. Don't hard-code algorithm names everywhere in your code; use formats that carry a key version and algorithm identifier (the key version field from Week 3), so that when the algorithm changes, only configuration and re-encryption are needed.

Worked example: generating post-quantum keys today¶

OpenSSL 3.5 supports the standardized post-quantum algorithms directly; you can generate them today, on your own machine, and compare their sizes with classical algorithms:

openssl genpkey -algorithm ML-KEM-768 -out mlkem.pem
openssl pkey -in mlkem.pem -pubout -out mlkem_pub.pem
wc -c mlkem_pub.pem

openssl genpkey -algorithm ML-DSA-65 -out mldsa.pem
openssl pkey -in mldsa.pem -pubout -out mldsa_pub.pem
echo hello > belge.txt
openssl pkeyutl -sign -inkey mldsa.pem -rawin -in belge.txt -out belge.mldsa.sig
wc -c mldsa_pub.pem belge.mldsa.sig
openssl pkeyutl -verify -pubin -inkey mldsa_pub.pem -rawin -in belge.txt -sigfile belge.mldsa.sig

1714 mlkem_pub.pem
2770 mldsa_pub.pem
3309 belge.mldsa.sig
Signature Verified Successfully

Compare with the table in Section 4:

The difference is striking: ML-DSA-65's public key is ~24 times larger than Ed25519's, and its signature is ~52 times larger. This shows that the move to PQC is not just "changing an algorithm name" — many places, such as the TLS handshake, certificate size, and the number of network packets, must account for this growth. NIST's recommended hybrid approach for TLS (like X25519MLKEM768, the version of Section 6's X25519 agreement run together with PQC) exists precisely to manage this transition cost: classical and PQC keys are used at the same time; if the classical side is broken, PQC still protects; if the PQC side (new, not-yet-proven math) is broken, the classical side keeps protecting.

Why lattice problems? A short intuition¶

RSA's security rests on "the difficulty of factoring a large number," ECC's security rests on "the difficulty of taking a discrete logarithm on a curve" — Shor's algorithm efficiently solves both on a sufficiently large quantum computer. ML-KEM and ML-DSA instead rest on lattice problems: in a multi-dimensional space, in a structure formed by regularly spaced points (a lattice), "finding the lattice point closest to a given point" or "solving a system of equations with small error terms" (Learning With Errors, LWE) is computationally very hard at high dimensions, and so far, no efficient solution has been found for either classical or quantum computers. "Not having been found so far" does not mean "will never be found" — which is why the hybrid approach is recommended.

This section was the final stop on the map we drew in Section 1: which algorithm, which problem, how secure, until when. From Section 13 onward you pour this knowledge into your own project's algorithm inventory.

13. Term project: this week¶

Draft the S8 and S11 sections expected at the final checkpoint:

• S8 — Algorithm inventory: for every algorithm used in your project, its purpose, key length, mode, the standard it rests on, and the library. If the table contains an obsolete algorithm, give its justification and a migration plan.
• S8 — Key lifecycle table: for every key, where it is generated, where it is stored, its crypto-period, and its renewal and destruction (Week 3).
• S11 — Secure communication: TLS version and validation; if pinning is used, the SPKI and backup pin; message-level protection.
• If your project has an update or configuration file, add signature verification (Ed25519 recommended) and reject rollbacks.
• Optional: use this week's root → intermediate → leaf chain for your project's test certificates; do not put the root key in the repository.

Worked example: filling in the S8 table for a sample component¶

Facing a blank table, it can be unclear what to write; let's see how S8 would be filled in for a sample project component ("user session token generation") — replace the rows with your own components in your own project:

The key lifecycle table (this week's counterpart to Week 3's key management topic) for the same component:

These two tables bring together, in a single place, every concept you've seen in Sections 1–12 of this week ("which mode," "which standard," "where it's stored," "when it's renewed") — an evaluator, at the final checkpoint, looks for exactly these two tables.

14. Work on your own¶

15. Self-check¶

16. Resources and further reading¶

Course textbook — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Recipe 5.2–5.4 (algorithm, key length, and mode selection), 5.11 (padding), 5.16 (an error-resistant API)
• Recipe 6.3–6.4 (digest and MAC selection), 6.10 (HMAC), 6.18 (combining encryption and integrity), 6.19 (rolling your own MAC — a warning), 6.21 (a MAC against replay)
• Recipe 7.1–7.3 (public-key usage and selection), 7.10–7.14 (RSA encryption, signing, and secure combination), 7.16–7.17 (DER and PEM)
• Recipe 8.15–8.19 (password-based key exchange, authenticated key exchange with RSA, Diffie–Hellman, DH + signature, authentication without PKI)
• Recipe 10.1, 10.4–10.5 (PKI and X.509 validation), 10.10–10.12 (CRL and OCSP)

Open standards and resources

• NIST SP 800-57 Part 1 (key management and security levels), SP 800-131A (algorithm transitions), SP 800-38A/D (modes, GCM), FIPS 186-5 (digital signature), FIPS 203/204/205 (post-quantum).
• RFC 2104 (HMAC), RFC 8017 (PKCS#1 v2.2: OAEP, PSS), RFC 8032 (Ed25519), RFC 7748 (X25519), RFC 5280 (X.509 and CRL), RFC 6960 (OCSP), RFC 6979 (deterministic ECDSA), RFC 8446 (TLS 1.3).
• OASIS PKCS#11 v3; SoftHSM documentation; OpenSSL 3 man pages (genpkey, req, x509, verify, ca, pkeyutl).
• MITRE CWE: CWE-327 (broken algorithm), CWE-326 (insufficient key length), CWE-295 (improper certificate validation), CWE-299 (missing revocation check), CWE-347 (improper verification of a signature), CWE-294 (authentication bypass by replay).