Chapter 17 — Cryptography concepts | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 17 published. Map, example, EX049.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["17.1 Hash functions"]
  N2["17.2 Digital signatures and keys"]
  N3["17.3 Confidentiality and authenticity"]
  N4["17.4 Evidence integrity in practice"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX049"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["17.1 Hash functions"]
  N2["17.2 Digital signatures and keys"]
  N3["17.3 Confidentiality and authenticity"]
  N4["17.4 Evidence integrity in practice"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX049"]

[Learning outcomes and connection]
    |
    v
[17.1 Hash functions]
    |
    v
[17.2 Digital signatures and keys]
    |
    v
[17.3 Confidentiality and authenticity]
    |
    v
[17.4 Evidence integrity in practice]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX049]

Learning outcomes and connection

You will be able to (1) explain hashes, digital signatures and keys at the level needed for incident work; (2) state what a hash does and does not prove about evidence; (3) evaluate integrity claims in an evidence manifest; and (4) identify the records needed to support provenance. Chapter 15 introduced provenance of measures; this chapter introduces cryptographic tools for the integrity of evidence. Chapter 25 uses hashes in a timeline lab.

17.1 Hash functions

A cryptographic hash function maps any input to a fixed-length digest; SHA-256 (specified in FIPS 180-4) produces 256 bits. Useful properties: any change to the input changes the digest unpredictably, and it is computationally infeasible to find two inputs with the same SHA-256 digest. MD5 and SHA-1 are broken for collision resistance and should not be used where an adversary could craft inputs, though they may still appear in legacy tools.

What a hash proves: that a file now is bit-for-bit identical to the file that was hashed earlier — if you can trust the earlier digest. What it does not prove: where the file came from, who collected it, when, or whether it was already altered before hashing.

17.2 Digital signatures and keys

A digital signature uses a private key to sign data (usually its hash); anyone with the public key can verify it. A valid signature proves that someone holding the private key signed exactly that data. It does not prove who held the key, unless key custody is documented, nor when signing happened, unless a trusted timestamp is attached (RFC 3161 defines a time-stamp protocol).

For the contractor's evidence, a signature on the manifest would show that a key holder signed those digests, but not which person, unless the contractor documents who controls the key.

17.3 Confidentiality and authenticity

Encryption provides confidentiality (only key holders can read). Authenticity and integrity come from signatures or message authentication codes. Encryption without authentication can allow undetected tampering; modern protocols (TLS 1.3, authenticated encryption modes) provide both.

A ZIP sent over an encrypted channel is protected from reading in transit, but the encryption alone does not tell the recipient that nobody altered it; only an authentication step does. For the contractor's delivery, encryption would keep the logs private while travelling, and a separately transmitted digest or a signature would be needed to show they arrived unchanged.

17.4 Evidence integrity in practice

An evidence manifest lists items with identifiers, digests, sizes, collection time, collector, method and storage location. The cryptographic part (digests) is strong; the procedural part (who, when, how) is what gives the digests meaning. A manifest's own integrity can be protected by signing it or storing it in a write-once system.

The contractor example shows the gap: the digests matched, but collection method, collector and time were missing, and the manifest travelled in the same ZIP as the files. Record the digest in the case system at collection time, so an independent copy exists from the start.

17.5 Worked example (synthetic): a manifest without provenance

Fictional. A contractor delivers to Harbourline a ZIP of three log files and manifest.txt listing SHA-256 digests. Recomputed digests match.

Supported: the three files received are identical to the files the contractor hashed. Not supported: that the files are complete exports, that they came from the claimed systems, when they were collected, or that they were unaltered before hashing. Also: the manifest arrived in the same ZIP as the files, so anyone able to alter the files could alter the manifest — matching digests show only internal consistency.

Additional records needed: the collection method and query used for each file; collector and time; a digest sent through a separate channel (for example by signed email or recorded in the case system at collection time); system-side evidence (for example the source system's export log) that the export occurred.

17.6 Common errors and limits

Treating a matching hash as proof of authenticity or completeness.
Storing digests alongside the data they protect, with no independent copy.
Using MD5/SHA-1 where adversarial collision matters.
Confusing encryption with integrity.
Hashing a file after it has been opened, converted or moved between operating systems, so the digest describes a changed copy.
Accepting a manifest that arrived in the same package as the files it describes as independent proof.
Assuming a signature shows when something was signed without a trusted timestamp.

Exercises — chapter 17

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX049 — Compute and compare. Steps: in Python, compute SHA-256 of the bytes b"case HC-0101\n" and of b"case HC-0101\r\n"; explain why they differ and why this matters when files cross operating systems. Rubric: 3 = digests computed, line-ending difference explained, advice to hash before any transfer or conversion; 2 = digests only; 1 = claim without computing; 0 = none.

EX050 — Evaluate claims. Inputs: four claims about §17.5: (a) "the logs are authentic"; (b) "the logs were not modified after the contractor hashed them"; (c) "the logs are complete"; (d) "the logs came from the firewall". Steps: mark each supported or not, with reason. Rubric: 3 = only (b) supported, and only relative to the manifest's own integrity; 2 = one error; 1 = all accepted; 0 = none.

EX051 — Design a manifest. Steps: list the fields of a manifest for evidence you collect yourself and how you protect it. Rubric: 3 = item ID, source system, query/method, collector, UTC time, size, SHA-256, storage location, access log; protection by independent recording and signature or write-once store; 2 = missing method or time; 1 = digests only; 0 = none.

Chapter synthesis

Hashes prove sameness, signatures prove key use, and neither proves origin, time or completeness. Pair cryptographic integrity with documented provenance and an independent record of the digests.