Hash to a ledger instead of putting data on one

short · 50 min · Objective 3.4

Task

Build the middle path -- tamper evidence with third-party verifiability and no data on a replicated store -- and then demonstrate why the alternative cannot support erasure.

Steps

  1. Write lab/chain.py maintaining a hash chain: each entry contains a hash of the previous entry plus a hash of a record, and nothing else.
  2. Add ten records, keeping the records themselves in an ordinary store with access control.
  3. Demonstrate tamper evidence: alter one record, recompute, and capture the chain verification failing in lab/chain-tamper.txt.
  4. Now demonstrate erasure: delete one record from the ordinary store and show the chain still verifies for every other entry while that one can no longer be proven -- which is the intended behaviour.
  5. Write lab/ledger-decision.md stating the one condition under which a distributed ledger would have been the right answer instead, and whether it holds for your lab.

Verify

python lab/chain.py verify; echo "verify exit=$?"
grep -Eic 'mismatch|invalid|tamper|fail' lab/chain-tamper.txt
grep -Eci 'mutually distrust|no party trusted|several parties' lab/ledger-decision.md

Verification passing on the intact chain, failing on the tampered one, and the decision file naming the mutually-distrustful-parties condition. Inside one organisation that condition is never true, which is why a database with signed entries wins.

This is an independent study companion for CompTIA SecurityX CAS-005 and is not produced by or endorsed by CompTIA.