It's time to close out Part 5. We've covered SHA-256, Merkle trees, inclusion and consistency proofs, and checkpoints with external anchoring. Now let's step back and ask: what does all of this actually stop — and what does it not stop? In security design, knowing precisely what you can't prevent is just as important as knowing what you can.
Quipu-Log is a tamper-evident system, not a tamper-proof one. That distinction defines the entire design.
tamper-proof vs tamper-evident: the decisive difference
Security systems fall into two philosophies.
| tamper-proof (prevent) | tamper-evident (detect) | |
|---|---|---|
| Goal | Make tampering impossible | Make tampering always detectable |
| Examples | HSM chipsets, physical locks | tamper-evident seals, Merkle trees |
| Against disk access | Requires hardware | Detected via external anchor |
| Quipu-Log's approach | ❌ (beyond a software library) | ✅ (the design goal) |
Achieving tamper-proof guarantees for an audit log through software alone is not possible. As long as a file lives on disk, someone with root access can always edit it. Quipu-Log's goal is to make that edit impossible to hide.
Think of a tamper-evident seal on a box. The seal doesn't lock the box — it doesn't stop you from opening it. But peel it off and reapply it, and it leaves a mark. The moment an auditor sees "this seal was broken," they know something is wrong. Quipu-Log's Merkle tree + external anchor plays exactly that role.
Threat model: who can do what
What each layer catches — and what it misses
Let's walk through the three-layer defense in order.
Layer 1 — Merkle spine (direct verification):
- Catches: in-place record edits, segment file substitution, leaf reordering
- Misses: rewriting the spine file itself along with the segments
Layer 2 — Signed checkpoints:
- Catches: tail truncation (tree_size decrease), full rewrite without the private key (signature mismatch)
- Misses: deleting the checkpoint file and re-signing (if the attacker has the key), full rewrite + re-sign by an insider
Layer 3 — External anchor:
- Catches: even a key-holding insider's full rewrite — the consistency proof against the anchored past root fails
- Misses: compromise of the external anchor system itself (a different trust domain's problem)
Blast radius: the scope of damage before detection
In security, blast radius means "how far does the damage spread if an attack succeeds?" In Quipu-Log:
- Single record edit: detected immediately on the next
verify_integrity()run. Blast radius is that one record. - Segment substitution: inconsistency surfaces at the next segment seal checkpoint. Blast radius is from the last checkpoint to the current segment.
- Full rewrite: detected when the anchor is checked. The time until detection is the blast radius. The shorter the anchor interval, the smaller the blast radius.
Two levers control blast radius: (1) Checkpoint frequency — sealing segments more often creates checkpoints more often. (2) External anchor verification frequency — if the anchor recipient runs consistency proofs on a regular schedule, the time to detecting a full rewrite is minimized. How often you run audits is an operational parameter.
Out of scope: deliberate design boundaries
SECURITY.md is candid about this. The following are intentionally out of scope:
Availability is not Quipu-Log's responsibility. If the single-writer daemon goes down, logging stops. This is a design decision, not a vulnerability — availability is the client's concern (quipu-client's spool and retransmission). Covered in Ch. 33.
Real-time blocking is not Quipu-Log's role. An audit log records things that already happened. Even if a malicious action makes it into the log, Quipu-Log does not block that action in real time. Real-time blocking belongs to application-level access controls.
Physical access and token theft are separate problems. SECURITY.md: "Out of scope: denial of service from an authenticated admin token, physical access to key files." If key files are stolen, the external anchor becomes the last line of defense.
Low-entropy field vulnerability under SHA-256 is a known trade-off. A field protected by SHA-256 (e.g., an SSN) can be brute-forced — an attacker could hash every possible value and compare. This is a known design limitation, and HMAC protection addresses it. Covered from Ch. 24 onward.
Summary: threat model on one page
| Attack scenario | Detection method | Prerequisite |
|---|---|---|
| In-place record edit | Merkle spine root mismatch | — |
| Full segment file substitution | Merkle spine root mismatch | — |
| Tail segment deletion | Checkpoint tree_size > current size | Checkpoint exists |
| Full rewrite without key | Checkpoint signature mismatch | Private key off data node |
| Full rewrite + re-sign with key | External anchor consistency proof fails | External anchor in a different domain |
| Availability attack (service disruption) | Out of scope | Client spool handles this |
| Real-time malicious action blocking | Out of scope | App-level access controls handle this |
Recap
- Quipu-Log is tamper-evident (makes tampering detectable). tamper-proof (preventing tampering) is not achievable at the software level.
- Three layers (spine, checkpoint, external anchor) each cover a different attacker model.
- Availability, real-time blocking, and physical access are out of scope — they are intentional design boundaries, not security vulnerabilities.
- Blast radius is tuned by the anchor interval and checkpoint frequency.
① Explain "tamper-evident, not tamper-proof" with your own analogy — something other than the tamper-evident seal.
② A key-holding insider rewrites the log. List three conditions that must all be in place for this attack to be detected.
③ You receive a request to "add a feature to Quipu-Log that blocks malicious API calls in real time." Explain why this request is outside Quipu-Log's design scope and which layer it properly belongs to.