All Posts by Date or last 15, 30, 90 or 180 days.

As an Amazon Associate I earn from qualifying purchases @AMAZON

Designed for the most demanding needs of photographers and videographers.
The fastest, toughest, and most compatible portable SSD ever with speeds up to 2800MB/s.

Integrity Checker: Tamper Detection for Files?

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.

Tamper detection

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:

icj update-auth
icj verify-auth

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.

Download page for existing customers.

Get IntegrityChecker Java

View all handpicked deals...

Seagate 22TB IronWolf Pro 7200 rpm SATA III 3.5" Internal NAS HDD (CMR)
$500 $400
SAVE $100

diglloyd.com | Terms of Use | PRIVACY POLICY
Contact | About Lloyd Chambers | Consulting | Photo Tours
Mailing Lists | RSS Feeds | X.com/diglloyd
Copyright © 2020 diglloyd Inc, all rights reserved.
Display info: __RETINA_INFO_STATUS__