Why SHA-256?
SHA-256 is a standard cryptographic hash in the SHA-2 family. It reads the bytes of a file and deterministically produces a 256-bit digest, normally written as 64 hexadecimal characters. The same bytes produce the same digest; even a small content change should produce a very different digest.
Creator uses SHA-256 because it combines strong modern collision resistance with broad interoperability. NIST encourages SHA-256 at minimum where hash interoperability is required, and SHA-256 is also the default algorithm used by PowerShell Get-FileHash.
What percentage of certainty does SHA-256 provide?
SHA-256 is not a classifier with an ordinary accuracy percentage. If an implementation reads the same bytes correctly, the calculation is exact and repeatable. A different file could theoretically share a digest, but for a particular unrelated difference the idealised chance is 1 in 2^256—about 1 in 1.16 × 10^77. That is computationally negligible for normal archive-integrity work, but it is more honest to say extremely strong evidence than mathematically impossible.
A matching hash proves agreement with the reference digest, not who created that reference. For authenticity, the manifest must come from a trusted source or be protected by a trusted signature or other controlled process.
Why add chunk-level evidence?
A whole-file digest is deliberately all-or-nothing: one changed byte makes the file fail. That is excellent for identity, but the digest alone cannot distinguish a tiny local difference from a completely different file.
Enhanced Corruption Data records SHA-256 for fixed 16 MiB regions as well as for the whole file. If the file later fails its whole-file check, Checker can compare the reference regions and report the percentage that still match. This supports diagnosis and triage; it does not repair the file or prove that a partly matching file is usable.
What Creator adds beyond a one-line hash command
- A manifest records the intended file set, relative paths, file sizes and whole-file SHA-256 values together.
- Optional enhanced data retains evidence that a normal whole-file digest discards.
- Portable TXT or CSV verification data can carry whole-file and chunk evidence in one documented dataset.
- Scope measurement, progress, results, summaries and activity logs make omissions and failures visible.
- Independent workspaces and queues support repeated archive jobs without rewriting scripts for every folder.
COMPARISON
Hash algorithms and checksums are not all interchangeable
| Method | Useful for | Important limitation |
|---|---|---|
| CRC32 | Fast accidental-error detection and format checks | Not designed to resist deliberate collisions; only 32 output bits |
| MD5 | Legacy compatibility | Broken for collision-resistant security; not a good choice for new trusted manifests |
| SHA-1 | Legacy verification where an old reference already exists | No longer approved for uses that require collision resistance |
| SHA-256 | Strong, widely interoperable file-integrity evidence | A digest alone does not authenticate its source or locate the changed region |
| SHA-512 | Strong SHA-2 hashing with a longer digest | Larger output and less common in checksum manifests; not automatically more useful for this workflow |
| SHA-3 | A standard alternative with a different internal design | Not a required replacement for SHA-2; interoperability may be lower in everyday checksum files |
Standards and technical references
These links provide primary technical context. They do not imply endorsement of NourForge.