Exercises: Applied Cryptography

These exercises move from reading a cipher suite to designing a data-protection scheme. Difficulty is marked ⭐ (recall/application), ⭐⭐ (analysis), and ⭐⭐⭐ (synthesis/open-ended). A dagger (†) marks problems with a full worked solution in Appendix: Answers to Selected Exercises — try every problem before you read one.

All addresses use documentation ranges; all domains use meridianbank.example. Where an exercise asks you to "grade" or "design," there is rarely one perfect answer — the reasoning is what matters. Work only against systems you own or are authorized to assess.

Part A — Core vocabulary and concepts ⭐

1.† In one sentence each, define data in transit and data at rest, then name the primary threat and the primary control for each.

2. Classify each as protecting data in transit, at rest, or both/neither: (a) TLS 1.3; (b) BitLocker; (c) a VPN; (d) tokenization of card data; (e) an HSM; (f) HSTS; (g) database TDE.

3. Explain forward secrecy in two sentences, and state what attack it defeats. Then name the property of a cipher suite (one word) that provides it.

4.† Define certificate pinning and mutual TLS (mTLS). For each, give one scenario at Meridian where it is the right control and one operational risk it introduces.

5. Expand these acronyms and say in one phrase what each is for: TLS, IPsec, FDE, HSM, CRL, OCSP, CT, mTLS, TPM, AEAD.

6. A datum (a customer's account number) is created in a web form, sent to the server, stored in the database, and copied to a backup. List the states it passes through and the control that should protect it at each step.

Part B — Read and grade the configuration ⭐⭐

7.† Read this cipher suite and label each of its four components, then judge it (good / flag it): TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

8. For each suite, state the single most important weakness a defender should flag: - (a) TLS_RSA_WITH_AES_128_CBC_SHA - (b) TLS_ECDHE_RSA_WITH_RC4_128_SHA - (c) TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - (d) TLS_AES_128_GCM_SHA256 (a TLS 1.3 suite)

9.† Grade this TLS config. A scan of legacy.meridianbank.example reports: protocols offered = TLS 1.0, TLS 1.1, TLS 1.2; forward secrecy = not on all suites; weak ciphers offered = 3DES; certificate = valid, expires in 220 days, RSA-2048. Assign a letter grade (A–F), list every finding, and write a two-line remediation plan in priority order. (Use the logic of this chapter's tls_config_grade.)

10. Two endpoints both earn a "B" from tls_config_grade. Endpoint X's only finding is "certificate expires in 9 days"; endpoint Y's only finding is "weak ciphers offered: 3DES." Are they equally urgent? Argue which you would remediate first and why the same grade can hide different urgencies.

11.† A junior analyst tests banking.meridianbank.example in their modern browser, sees a strong AES-256-GCM connection and a padlock, and concludes "TLS is fine here." Explain why this conclusion is unsafe and what they should have checked instead.

Part C — Analyze this (telemetry & scenarios) ⭐⭐

12.† You are handed this (illustrative) excerpt from a load balancer's TLS-negotiation log for the online-banking endpoint. All times UTC; source IPs in the documentation range 203.0.113.0/24.

09:14:01  src=203.0.113.20  proto=TLSv1.3  cipher=TLS_AES_128_GCM_SHA256   result=OK
09:14:02  src=203.0.113.20  proto=TLSv1.3  cipher=TLS_AES_256_GCM_SHA384   result=OK
09:31:55  src=203.0.113.77  proto=TLSv1.0  cipher=TLS_RSA_WITH_RC4_128_SHA result=OK
09:31:56  src=203.0.113.77  proto=TLSv1.0  cipher=TLS_RSA_WITH_RC4_128_SHA result=OK
09:31:58  src=203.0.113.77  proto=TLSv1.0  cipher=TLS_RSA_WITH_RC4_128_SHA result=OK

(a) What stands out about the 09:31 connections? (b) What does it tell you that result=OK — i.e., the server accepted them? (c) Is this evidence of an attack, a misconfiguration, or both? (d) Name two actions: one immediate (configuration) and one investigative.

13. A customer reports that Meridian's mobile banking app suddenly stopped connecting after they installed a "free WiFi security" app on their phone, while the phone's browser still reaches the bank fine. Using §5.6, explain the most likely cause and why the app behaves differently from the browser.

14.† Meridian's status page shows the online-banking site went hard-down at 00:00 UTC with clients reporting certificate errors; nothing was deployed. In two sentences, give the most likely root cause and the single inventory/automation practice that would have prevented it.

15. An attacker on a coffee-shop network sets up a rogue access point and tries to MITM a customer's connection to banking.meridianbank.example (TLS 1.3, valid certificate, no pinning on the browser). Describe what the attacker must do to read the traffic, why plain interception fails, and what the customer would see if the attacker tries the only viable path.

Part D — Harden it ⭐⭐

16.† Harden it. Here is a (simplified, illustrative) TLS policy block for a web server. List everything wrong and write the corrected policy intent (you may describe it in prose; exact syntax is not graded).

protocols:  SSLv3, TLSv1.0, TLSv1.1, TLSv1.2
ciphers:    ALL:!aNULL          # "everything except no-auth"
prefer_server_cipher_order: false
hsts:       (not set)

17. Harden it (at rest). A team reports: "The customer database uses Transparent Data Encryption, so cardholder data is encrypted at rest — we're compliant." Identify two ways this could still leave card data exposed, and recommend a stronger design using concepts from §5.5 (consider key location and tokenization).

18. Harden it (VPN). Meridian's remote-access VPN allows username+password login, runs on an appliance last patched 14 months ago, and treats any connected device as fully trusted on the internal network. List the three most important hardening changes and justify each in one line.

Part E — Write it / design it ⭐⭐–⭐⭐⭐

19.† Write the policy. Draft a 6–10 line TLS configuration standard for Meridian's public-facing web properties: allowed protocols, required cipher properties, certificate requirements (key size, signature algorithm, max lifetime, renewal), and one monitoring requirement.

20. Design the scheme. Meridian is launching a new feature that stores customers' scanned ID documents (driver's licenses) for identity verification. Design the data-protection scheme: how is each document protected in transit (upload and internal transfer) and at rest (storage, backup)? Where do the keys live? Name one threat your design defeats that simple TDE would not.

21.† Design it. Meridian's microservices currently authenticate to each other with a shared API token passed in a header. Design a migration to mTLS for service-to-service authentication. What new lifecycle burden does this create, and what from §5.6 helps manage it at scale?

22. Choose the VPN. For each scenario, choose IPsec, WireGuard, or a TLS-based VPN and justify in two lines: (a) connecting a new branch's firewall to the data center, interoperating with existing gear; (b) giving 200 remote staff laptops access that integrates with the identity provider and traverses hotel/airport networks; (c) a fast, simple tunnel between two cloud VPCs managed by the engineering team.

23. Design it. Write the certificate-lifecycle process for Meridian: who owns it, how renewal is automated, how expiry is monitored and alerted, how revocation is handled, and how mis-issuance is detected. Map each step to the lifecycle in Figure 5.2.

Part F — CTF-style challenge ⭐⭐⭐

24.† The certificate that should not exist. Meridian's CT-log monitoring fires an alert: a public CA has issued a certificate for secure-login.meridianbank.example — a hostname Meridian has never used and never requested. The certificate is valid, trusted by browsers, and was issued yesterday. (a) What does this most likely indicate, and why is it dangerous even though Meridian's own servers are untouched? (b) What can an attacker do with this certificate? (c) List, in order, the defensive actions Meridian should take. (d) Which control from this chapter would have protected Meridian's mobile app customers even before the certificate was caught?

Part G — Interleaved & forward-looking ⭐⭐

25. (Interleaved with Ch.4.) Chapter 4 introduced hashing and digital signatures. Explain how a CA uses a digital signature to create a certificate, and how a client uses the CA's public key to verify it — then connect this to why a mis-issued certificate (Exercise 24) breaks the whole trust model.

26. (Interleaved with Ch.1.) Score the risk (likelihood × impact, 1–5, with the bands from Chapter 1) of: (a) the forgotten TLS-1.0 microsite from the chapter opening; (b) a 5-day-to-expiry certificate on the main banking portal; (c) a remote-access VPN with no MFA. Rank them and state which you fix first.

27. This chapter mentioned that "on the VPN" should not equal "trusted," and that network access should remain least-privilege. Based only on that hint, write two sentences predicting what idea later in the book replaces perimeter trust, and why a compromised laptop on a VPN motivates it.

28. ⭐⭐⭐ Open reflection. The chapter argues that cryptographic failures are almost always operational (lifecycle, key management), not mathematical. Pick a real, publicly reported outage or breach you can find that was caused by an expired certificate, a leaked private key, or a TLS misconfiguration (not an algorithm break). Summarize what failed in the lifecycle and which practice from §5.6 or §5.7 would have prevented it. (Cite your source; tier it.)

Solutions to daggered (†) problems are in the Answers appendix. The remaining problems are deliberately open — bring them to a study group or your instructor.