Is the report seal a digital signature?
The forensic report carries an HMAC-SHA256 seal over its canonical JSON body. It is a shared-secret message authentication code, not a public-key signature: anyone with the same key can create or verify it, so it cannot by itself prove who produced the report or when. If you omit the key, the built-in default secret is public; use the --key option and protect that secret.
How Aureal handles it
The seal is computed over the report body with the signature object removed, using sorted-keys JSON canonicalisation, and the comparison uses a constant-time equality check. The signature object records the algorithm, the canonicalisation version and what it covers. That design makes any edit to a covered field detectable, including the verdict, payload ID, metrics and file hashes. It does not create asymmetry: the same secret both creates and checks the seal, so a holder can re-seal a modified report. The built-in default secret is a fixed public constant; a report sealed with it can be reproduced by anyone, so it cannot evidence possession of a private key.
Common failure mode
“The HMAC seal is a cryptographic signature that proves the label produced the report.”
Why it fails: An HMAC is symmetric. It proves that someone with the secret produced the seal and that the covered bytes have not changed, not who that someone was. With the public default, even the first part is weak. Identity needs a public-key signature or an independent chain of custody, neither of which the seal provides.
Verified example
Seal with a private secret, verify with the same secret, and store the key separately from the report:
node aureal-watermark.cjs detect evidence.mp3 --id 883921 --report proof.json --key "$AUREAL_SEAL_KEY"
node aureal-watermark.cjs verify-report proof.json --key "$AUREAL_SEAL_KEY"
# exit 0 = body unchanged and same key; 1 = modified or wrong key
The report does not identify its author, and the sealed timestamp is self-asserted.
Example only. Validate against your own audio, codec and processing chain.
Scope and limits
- Shared secret, not a public-key signature.
- The built-in default secret is public; use the --key option.
- A valid seal does not establish authorship, ownership or scan time.
- Anyone holding the key can create a valid seal over a different report.
Frequently asked questions
Can I publish the report and the key together?
You can, but then anyone can re-seal a modified report and the seal stops distinguishing your version. Publish the report; keep the key with the party that is supposed to verify it.
Does a valid seal prove the scan happened?
It proves the covered fields match the secret. The timestamp is written by the generating machine and is covered by the seal, but nothing independently attests that the clock was correct or that the scan occurred at that moment.
Related topics
Test the actual delivery chain. A fixture result is a starting point, not a guarantee for your material.
Open the Studio →