HashKeeper stores hash values of “known to be good” files, such as those from an install of a software package, and hash values from “known to be bad files, such as those from child pornography, malware and planted files. When examiners compare the known to be bad hash values against the hash values from an unknown file system they can quickly and reliably focus their attentions on those files most likely to be probative. Matches against known to be good file hashes allow the examiner to reliably overlook those files on the unknown file system.

HashKeeper was intended to be open so that investigators could share their efforts with other investigators much the way law enforcement has been sharing their efforts for the last hundred years or so.

Provenance – HashKeeper was never intended to prove provenance. Provenance only becomes an issue in copyright crimes.

Admissibility – This is a curious issue. When known to be good hash values are used to eliminate files from an examination admissibility is a non-issue. In the American legal system, and I suspect the majority of legal systems, no one is required to prove the provenance or worry about admissibility of things not presented in court. As for matches with known to be bad files the match alone is meaningless (the whole probability thing). The responsibility still rests with the examiner to show that what’s being introduced is probative.

Specificity – HashKeeper started with MD5 hash values. MD5 is reliable. The likelihood of a false positive or false negative with MD5 is really, really, really small and then really, really smaller than that. Adding SHA-1 and CRC 32 to the comparisons makes an already absurdly unlikely event more absurdly unlikely. The benefit is unclear.