What do the report's SHA-256 and SHA-512 hashes prove?
The report records SHA-256 and SHA-512 digests of the target file's bytes. Re-hashing the same file and comparing the values shows whether the bytes changed after the scan. The hashes say nothing about who created the audio, who owns it, or when it was made; they are an integrity record, not a provenance proof.
How Aureal handles it
Both digests are computed over the file as stored, including its container and metadata. That is useful for evidence handling: a tag edit, a re-encode or a single flipped byte changes the hash even when the audible content is the same. It also means a matching hash identifies the exact byte sequence that was scanned, not an earlier master from which it was derived. The text certificate shortens SHA-512 for display, so compare against the JSON when the full value matters. Because both hashes are inside the HMAC-covered body, changing them breaks the seal unless the editor also holds the key.
Common failure mode
“A matching SHA-256 proves this file is the original master.”
Why it fails: A hash identifies bytes, not origin. Any copy with identical bytes has the same digest, and anyone can compute a hash of any file. A match only shows that the file you hashed is byte-identical to the file described in the report; it does not show who made either one or when.
Verified example
Compare the evidence file with the record, using both digests:
sha256sum evidence.mp3
sha512sum evidence.mp3
# compare with targetFile.hashes in proof.json
On Windows: certutil -hashfile evidence.mp3 SHA256
If the values differ, stop and establish why before relying on the report.Example only. Validate against your own audio, codec and processing chain.
Scope and limits
- Integrity of the recorded bytes only.
- A tag or container edit changes the hash without changing the audio.
- No authorship, ownership, creation time or chain of custody.
- The text certificate shortens SHA-512; use the JSON for the full digest.
Frequently asked questions
Why record both SHA-256 and SHA-512?
They are independent digests of the same bytes. SHA-256 is sufficient for accidental-change detection in normal use; SHA-512 adds a second, longer value at little cost. A mismatch in either is a signal to investigate.
Does a different hash mean the file was tampered with?
Not necessarily. A re-encode, a metadata edit or a different export produces a different hash with no malicious intent. Compare the provenance and the audio, not just the digest.
Related topics
Test the actual delivery chain. A fixture result is a starting point, not a guarantee for your material.
Open the Studio →