Tamper-evident vs tamper-proof: what a record can show
Learn what tamper-evident means, what AuditIt’s default public check covers, and why a matching record does not prove the facts of a condition dispute.
By AuditIt Editorial Team · Fact checked
What to know
- Tamper-evident means alterations can become detectable; it does not mean changes are prevented.
- AuditIt’s default public Valid result checks recorded verification fields, not stored file bytes.
- A PDF byte rehash and an original-media byte rehash are separate, time-specific checks.
- Record integrity does not establish scene accuracy, cause, safety or liability.
Tamper-evident means a process makes alterations detectable; tamper-proof would imply that changes cannot be made. Those are different promises. AuditIt creates tamper-evident records, not tamper-proof files. Its default public verification result also must not be confused with re-reading stored file bytes.
For a condition record, the useful question is not simply “Is it secure?” Ask what was checked, which record or file was checked, what result was shown and when. That keeps an integrity check separate from a judgment about the condition described.
What does tamper-evident mean?
The NIST CSRC glossary defines tamper evident as “A process which makes alterations to the data easily detectable.” This is a definition about detecting data changes, not a promise that data cannot be edited.
Hashing is one way to support change detection. A hash algorithm produces a digest from data, which can be compared with a recorded digest. The Secure Hash Standard describes digests as a way to detect whether messages have changed since their digests were generated.
A mismatch does not, by itself, tell you who changed a file, why it changed or whether the change was deliberate. NIST IR 8387 discusses the need to assess changes when a hash comparison fails. Its audience is evidence-management professionals; citing it here does not turn an ordinary condition record into a forensic procedure.
Compare the claim with the check
| Statement | What it means | What it does not establish |
|---|---|---|
| Tamper-evident | Alterations can become detectable. | Does not make a change impossible or guarantee detection of every alteration. |
| Default public Valid | Recorded verification fields match the AuditIt verification record. | Does not re-read stored PDF or original-media bytes. |
| PDF byte rehash passed | The stored PDF was re-read and matched its recorded hash at the time shown. | Does not establish a separate original-media byte check. |
| Original-media byte rehash passed | The checked original media matched their recorded hashes at the time shown. | Does not establish what happened in the scene or who is responsible. |
Swipe horizontally to view every column.
The first row describes a property of a recordkeeping process. The other rows describe different verification results. They are not interchangeable badges, and a passing PDF check must not be presented as a passing original-media check.
What AuditIt’s default public Valid result means
AuditIt’s default public verification checks the recorded manifest, report content and associated verification records. Its Valid wording is specific:
This report's signed manifest, report hash, PDF hash record, signature/refusal records, and persisted evidence hash metadata match the AuditIt verification record.
Read a warning or invalid result together with its details. Do not rename it as a successful check, or treat it as an automatic accusation against someone involved in the record.
When a stored-byte rehash result is shown
A deep PDF check and a deep original-media check have different scopes. Where a passed PDF rehash is shown, AuditIt’s label says:
The stored PDF bytes were re-read from storage and matched the recorded SHA-256 hash at the time shown.
Where a passed original-media rehash is shown, the label says:
Original media bytes were re-read from storage and matched their recorded SHA-256 hashes at the time shown.
These are examples of result labels, not a report that those checks ran on your record. Keep the checked object and the time attached to the result. If a rehash was not run or its result is absent, leave that check unclaimed.
A checked record is not a verified account of the scene
Matching record data is different from establishing that an observation is accurate or complete. It does not decide when damage happened, what caused it, whether equipment is safe or who should pay.
The distinction also matters for photographs. A gallery file’s import time records when it entered AuditIt; it is not the source file’s capture time or location. A matching hash does not fill in missing scene context.
How to describe a condition record clearly
- Name the record. Identify the audit or report being discussed, rather than referring vaguely to “the evidence”.
- Name the check. Use the exact displayed result. Keep a default public check, a PDF byte rehash and an original-media byte rehash separate.
- Keep the scope and time. For a deep result, state which object was checked and retain the time shown. Do not extend it to other files or later versions.
- Separate observations from decisions. Keep missing context, questions and the reviewer’s conclusions distinct from the verification result.
Hypothetical example: a hire team shares a return record whose public page shows Valid. A clear summary is “The recorded verification fields match; this view did not run a stored-byte rehash.” It is not “These photos prove who caused the damage.” The first describes the check; the second adds a conclusion the check did not make.
Where AuditIt fits
AuditIt supports before/after condition comparisons and single-visit records. If you are setting up a handover process, start with the equipment checkout and return workflow. For a different record structure, see how to build an audit workflow template.
Ready to organise a condition record? Create an AuditIt account and choose a workflow that matches the visit you need to record.
Direct answers
Frequently asked questions
What is the difference between tamper-evident and tamper-proof?
Tamper-evident concerns making alterations detectable. Tamper-proof would imply preventing changes. AuditIt uses tamper-evident language; it does not promise that files cannot be edited or that every alteration will always be detected.
Does AuditIt’s Valid result mean original files were re-read?
No. The default public Valid result concerns recorded verification fields. The default view does not re-read stored PDF or original-media bytes. Describe a stored-byte rehash only when that deep verification result is shown.
Does a matching PDF hash mean the original photos were checked?
No. A stored PDF byte rehash and an original-media byte rehash are separate checks. A passed PDF result applies to the PDF and time shown; it does not establish that original media were re-read.
Does a hash mismatch prove deliberate tampering?
No. A mismatch identifies a failed comparison, not a person’s intent or the cause of a change. Read the result details and keep any investigation or conclusion separate from the hash comparison.
Can a hash prove when a photograph was taken?
No. A hash comparison concerns data integrity, not the truth of a scene or its capture time. A gallery file’s import time is also not its original capture time or location. Keep those facts separate when reviewing a condition record.
Do the NIST sources certify AuditIt or establish liability?
No. The cited NIST sources explain terminology and hash-based change detection. They are not a certification of AuditIt. AuditIt creates tamper-evident, human-review-ready records; it is not legal certification and does not determine liability.
Sources
- Tamper evident — CSRC Glossary, NIST Computer Security Resource Center
- FIPS 180-4: Secure Hash Standard (SHS), National Institute of Standards and Technology
- NIST IR 8387: Digital Evidence Preservation — Considerations for Evidence Handlers, National Institute of Standards and Technology
- tamper-evident
- condition records
- public verification
- hashes
- evidence integrity
