Chapter 1 — Computing systems
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 Layers an implementer touches"]
N2["1.2 Where cryptography lives"]
N3["1.3 Quantum computers in one page"]
N4["1.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 Layers an implementer touches"]
N2["1.2 Where cryptography lives"]
N3["1.3 Quantum computers in one page"]
N4["1.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 Layers an implementer touches]
|
v
[1.2 Where cryptography lives]
|
v
[1.3 Quantum computers in one page]
|
v
[1.5 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) describe the hardware, firmware, OS, library and application layers of a service; (2) locate cryptographic functions and keys in each layer; (3) explain what a quantum computer is and is not; and (4) estimate how hard a cryptographic change is from the layer where it lives.
1.1 Layers an implementer touches
Every KLS service sits on a stack. Servers and scanners have processors, memory, TPMs and network cards; firmware boots them and checks signatures on the next stage; an operating system or hypervisor isolates workloads; libraries such as OpenSSL, BoringSSL, Go's crypto packages or Java's providers implement protocols; applications call those libraries; and managed services (load balancers, CDNs, cloud key-management services) wrap the whole thing. Implementers change cryptography mostly in the middle layers — library versions, configuration, certificates — but must know the layers above and below because they constrain what is possible.
1.2 Where cryptography lives
Cryptography appears at every layer: secure boot signatures in firmware; disk encryption and keystores in the OS; TLS, SSH and IPsec in libraries and daemons; JSON Web Token signatures and field encryption in applications; HSMs or cloud KMS holding root keys. Each location has a change mechanism: configuration (minutes), package upgrade (days), vendor release (months), hardware replacement (years). Writing down the mechanism next to each cryptographic use is the single most useful habit for planning work.
For KLS the habit pays off at once: the API gateway's TLS groups are a configuration change, the ingress library is an image rebuild, the scanners' bootloader is a hardware refresh.
1.3 Quantum computers in one page
Quantum computers manipulate qubits whose joint states interfere; specific algorithms exploit this. Shor's algorithm (Shor, 1997) finds hidden periods and so breaks RSA, Diffie–Hellman and elliptic-curve cryptography; Grover's algorithm (Grover, 1996) gives only a square-root speed-up for brute-force search, so AES-256 and SHA-256 stay fit for purpose. Breaking RSA-2048 needs a large error-corrected machine; Gidney (2025) estimated under a million noisy qubits running for under a week under stated assumptions, and no such machine exists. For implementers the practical message is simple: replace public-key key exchange and signatures; keep symmetric encryption and hashes at adequate sizes.
1.4 Worked example
KLS's warehouse scanner: TPM-less ARM board (hardware), vendor bootloader verifying RSA signatures (firmware, change by hardware refresh), embedded Linux (OS, vendor image), libcurl with an old TLS library (library, vendor release), and a scanning app that uploads manifests over HTTPS (application, KLS code). Of five layers, KLS directly controls one. The scanner's TLS key exchange can only become hybrid when the vendor ships a new image.
The table also shows where KLS can act now. The upload path can be shortened so manifests leave the scanner only once a day, and the vendor contract can be amended to require an image with hybrid TLS by a named date. Both are recorded against the scanner row, so the residual risk is owned rather than forgotten while the refresh is pending.
1.5 Practical activity
For one service you administer in a lab, list each layer, one cryptographic function in it, and the change mechanism. Mark which you control.
A worked line for a lab web server might read: library layer, OpenSSL 3.5 providing TLS key exchange, changed by package upgrade, controlled by you; firmware layer, UEFI secure boot with an RSA-signed shim, changed by the board vendor, not controlled. Aim for at least five rows. Where you cannot name the mechanism, write "unknown" rather than guessing, and note which document or person could answer it. Keep the table; the inventory schema built in Chapter 4 imports exactly these columns.
1.6 Common errors and limits
- Assuming an application change can fix firmware cryptography.
- Treating quantum computers as general accelerators.
- Forgetting managed services that terminate TLS on your behalf.
Each error has a KLS example. A developer proposing to "fix" the scanners' RSA bootloader in the upload app is changing the wrong layer; only the vendor's refresh reaches firmware. Expecting a quantum computer to speed up log processing confuses a narrow cryptanalytic capability with general computing. And the CDN, not KLS, terminates browser TLS: forgetting it means the inventory shows the origin settings while customers actually negotiate with the provider's edge. The limit of this chapter is breadth: it maps layers but does not yet measure them.
Exercises
- EX001 — Layer table. Build a five-layer table for KLS's customer portal with function, change mechanism and owner. Rubric: 3 = five plausible rows.
- EX002 — Keep or replace. Classify RSA-2048 signatures, AES-256-GCM, SHA-256 and ECDHE P-256 as keep or replace, with one reason each. Rubric: 3 = four correct with reasons.
Synthesis
Cryptography lives in every layer, and the layer determines who can change it and how fast. Quantum computers threaten public-key key exchange and signatures, not symmetric encryption or hashes.