A Perfect Hash Can Preserve a Perfect Lie

A recording can survive every integrity check and still be an unreliable account of what happened. The file may be exactly the file collected. The camera may have pointed in the wrong direction, the clock may have been wrong, the export may have omitted crucial frames, or the scene may have been staged. Digital forensics has tools for detecting some kinds of alteration. It does not make the contents of an unaltered file automatically true.

False Normal repeatedly places different kinds of records beside one another: notebooks, photographs, electronic measurements, and separate clocks. That practice anchors this article without requiring the novel's explanation of its anomalies. Cyberdelia's angle is evidence infrastructure. The interesting question is not whether paper defeats computers. It is whether an investigation has preserved genuinely independent ways to discover that its preferred account is mistaken.

A cryptographic hash is a compact value computed from data. Comparing a reliably recorded earlier hash with a later one can help establish whether those bytes changed. The comparison is powerful precisely because it answers a limited question. It does not tell you whether the earlier file was complete, whether its metadata was accurate, or whether the sensor measured what its operator thought it measured. The investigator must establish those propositions through other means.

NIST's guidance on integrating forensic techniques into incident response separates collection, examination, analysis, and reporting. Its digital evidence preservation work also addresses the practical handling of evidence over time. Those distinctions are useful because a chain of custody is a record of handling, not a magic substitute for analysis. Good custody can preserve a misleading artifact extremely well. Poor custody can undermine an artifact that would otherwise have been informative.

Take a camera export described as the original video. There may be an original recording on the device, a file created by the export process, and a version produced by an investigator's conversion tool. All three deserve distinct names. The export could alter the frame rate, insert a timestamp overlay, or package audio differently. None of that necessarily implies misconduct. It does mean that calling every version original erases the steps needed to understand how the evidence reached the reader.

A useful evidence record would identify the device, collection method, software version, settings, and transformations, along with who performed each action and when. It would retain the collected file and distinguish working copies. If something was unavailable, that absence would remain explicit. A missing configuration should not quietly become an assumed default. Precision about the route from event to artifact is often more valuable than a grand claim that the evidence is authentic.

Independence is equally easy to overstate. Two dashboards may look like corroboration while reading from the same database. Three witnesses may repeat a claim they all encountered in one message. Two cameras may share the same synchronization service, firmware defect, or video processing pipeline. Counting outputs does not count independent observations. Before treating agreement as corroboration, an investigator should map the dependencies that could make every output wrong in the same way.

This is where an analog record can be useful without acquiring mystical authority. A handwritten observation made at the time may survive a failure of a digital system. A physical clock can provide a comparison with a device's clock. But handwriting can be mistaken or altered, and an analog clock can drift. Its value comes from a different failure path and documented provenance. Independence is a relationship between methods, not a virtue bestowed by the absence of a screen.

The same principle applies to an organization's incident response. If the logging service, administrator account, and monitoring console share one compromised control plane, agreement among them may offer less reassurance than it appears to. Separately controlled records can make an attack harder to conceal. Yet more copies also create costs and privacy obligations. An evidence architecture should identify the claims it must be able to test, then choose independent records that answer those claims. Keeping everything forever is a poor substitute for that design work.

Investigators also need to preserve inconvenient material. A sequence that fits a hypothesis can attract attention while an ambiguous reading is dismissed as noise. The excluded reading may eventually prove irrelevant. Keeping it, together with the reason for excluding it from the main analysis, leaves the decision open to review. Deleting it because it does not fit turns a tentative interpretation into a self-protecting story.

Reports should separate observation from inference at sentence level. A file records a door opening at the timestamp displayed by the recording system. The conclusion that a particular person opened it at a particular wall-clock time requires additional evidence. The difference sounds pedantic until a timing error or mistaken identification changes the conclusion. Readers need to see the steps that connect an artifact with a claim, and they need to know where a step remains uncertain.

There is a social dimension to this precision. Institutions often compress technical uncertainty into decisive labels because decisive labels fit forms, dashboards, and public statements. An investigator may know the limitations while the final report drops them. The result can be a certainty upgrade that no new evidence justified. Good reporting preserves the relevant uncertainty through that compression. It should not require a reader to reconstruct it from an appendix after the headline has already settled the matter.

The practical test is whether another qualified person can retrace the analysis, identify the assumptions, and attempt to disprove the conclusion. That person does not have to agree. Reproducibility is valuable because disagreement becomes inspectable. A trusted tool, signed report, or immutable storage system should help that process rather than shield the conclusion from it.

Evidence integrity matters enormously. Its meaning becomes clearer when we stop asking it to do everything. Preserve the bytes, document the handling, calibrate the instruments, map shared dependencies, and keep the reasoning available for challenge. A perfect hash is one strong link in that chain. Asking it to certify reality is how a careful technical practice becomes a very confident mistake.