Tensions in Practice: Local transfer checks in tension with lifecycle coverage¶
Two-hop transfer · accidental relay-memory change
A payload arrives correctly at a relay, then changes from A to B in memory before the relay creates the next hop’s check. That next check can accurately describe B, so both network transfers pass while the destination receives the wrong original content. Keeping an original comparison marker through the journey can expose this selected gap. The marker’s own integrity and the chosen check still matter.
Keep integrity handling local
Check each transfer without maintaining another reference across the entire route.
Detect changes across the whole journey
Compare the final content with what the original source actually supplied.
Why these aims pull against each other
Recomputing a check at every boundary can reset the reference after an intervening change. Coverage depends on where the reference begins and whether it survives unchanged, not simply how many checks passed.
Choose an arrangement to see what changes and what remains difficult.
Finite illustrative comparisons. Labels carry the meaning; color does not establish a preference or measured effect.
What this choice protects
What it costs
When it fits
Compare the arrangements
Check each hop locally
Validate the first transfer, then compute a fresh check for the outgoing payload. The selected memory fault occurs after the first validation and before that fresh check is created.
| Payload | Check basis | Result | |
|---|---|---|---|
| Source sends | A | Check for A | Sent |
| At relay | A | Matches A | Hop pass |
| Relay fault | BA changed to B | New check for B | Fault missed |
| End receives | B | Matches B | Hop pass |
- What it protects
- Each hop can validate its own transfer with local state and independently manage its transport checks.
- What it costs
- The selected between-checks memory change becomes the new outgoing baseline and passes undetected.
- When it fits
- Fits a deliberately narrower transfer-only assurance boundary when internal relay integrity is established separately and the residual gap is acceptable.
Illustration note: Both checks work as specified in this history. They simply do not certify that the relay’s outgoing content equals the original source content.
Retain the original marker
Carry or separately retain the source’s original check and compare the destination payload against it. The selected fault changes only the payload; the reference survives.
| Payload | Check basis | Result | |
|---|---|---|---|
| Source sends | A | Check A | Sent |
| At relay | A | Keep A | Go on |
| Relay fault | BA changed to B | Keep A | Not yet checked |
| End receives | B | Check A | Fault found |
- What it protects
- The final B payload disagrees with the retained A reference, exposing this intervening change.
- What it costs
- The reference must be retained and protected, and end-to-end computation and comparison add work beyond local transfer checking.
- When it fits
- Fits a promise to deliver the original content unchanged and a check/reference scheme adequate for the expected accidental-error model.
Illustration note: A and B are symbolic contents whose selected checks differ. A check collision or simultaneous corruption of payload and reference can defeat the intended detection.
What this illustration does—and does not—establish
Data Integrity: End-to-End Integrity Across Distributed Systems supplies protection-scope composition; Data Integrity: Silent Corruption Is Often Undetected supports end-to-end checking and the limitations distinguish integrity from authenticated origin. The finite timeline exposes the reset reference.
- This is an accidental-error example, not protection against an adversary who can replace both content and its unauthenticated check.
- Detecting disagreement does not recover the correct content or establish that the original content was accurate.
- Legitimate transformations require a different declared integrity scope; the toy promises unchanged transport.
Source entries
Data Integrity
Data Integrity: End-to-End Integrity Across Distributed Systems supplies the conflict examined here.
End-to-End Integrity Across Distributed Systems
Weak links undermine the chain. Failure mode: integrity protected at one layer but lost at another (verified by app but corrupted in transit; signed at source but corrupted at rest); requires holistic architecture review.
Silent Corruption Is Often Undetected
Without end-to-end checksumming, bit- level corruption at any stage (storage, network, memory, driver) can propagate silently.
What It Is Not
Plain SHA-256 provides integrity against accidental error but not proof of authenticity.