Consider IntegrityChecker’s data integrity verification: it proves that a file is unchanged vs modified. If you’re a professional and not using it in this age of bad actors, software bugs, etc, think again.
IntegrityChecker proves, based on a stored hash, that a file has not been modified.
But what if a bad actor modifies files and then recomputes and updates the hashes, making it appear that nothing has changed? Or you just want to know that the file is not only intact, but the authorized/correct version of a file?
A law firm or other professional firm might wish to prove that no tampering has occured. Even a workgroup might want such guarantees; for example embezzlement followed by changing internal records, or other internal malfeasance.
This proof of no tampering can be done very simply: an optional pass to add a tamper-detection hash to the existing data-verification hash. It could be done in seconds for millions of files that already have data integrity hashes.
The added requirement would be for the user to input a secret eg a password or passphrase known only to that user, and never stored on a computer:
HASH( verificationHash • <secret> • <salt>) ===> tamperDetectionHash
I contemplate various forms of this approach, including per-file salt data, compartmentalized secrets, optional inclusion of file names and/or attributes into the computation, choice of hashing algorithm, attached or separate storage of the hash/salt/etc, inclusion of optional information or metadata (eg a personal note), and so on. Independent of language or implementation, command line or GUI implementation, hardware or software.
Adding this capability to IntegrityChecker is straightforward:
Above, "auth" = "authenticate" eg detect tampering. Updating would be take seconds, even for millions of files*. Verification would act like icj verify, first computing the current hash and then the tamper-detection hash.
* Authentication hashes require existing data integrity hashes, but an option could allow for one-pass updates of both, eg icj update --auth=changed|all
Get Data Integrity Assurance now
Still guessing whether your backups suck?
Sudden unpleasant need to restore data, but no way to know if the backup has been corrupted?
All professionals should be using Integrity Checker, and it runs cross platform on macOS/Windows/Linux/any system with Java support eg everything. Moreover it’s not one of today’s crapified apps that needs updates every week and will be no good in a year or two, since it needs only a Java virtual machine, which has a decades-long track record of compatibility.