How hashing is working?

A proof record is a compact, tamper-evident reference to a file. It contains a cryptographic fingerprint (hash) and a timestamp anchored in an immutable registry (blockchain). Later, anyone can verify whether a file is still the same as the recorded original—without seeing the original content.

Verify a file Create a proof record

What a fingerprint is

A fingerprint is a short string computed from the file’s bytes. It has one job: same file → same fingerprint. If anything changes—even one byte—the fingerprint changes too.

How a hashing algorithm works

Hashing turns an input of any size into a fixed-size output. The steps are simple:

• Read bytes — The file is processed as raw bytes, not “meaning” or format.
• Split into blocks — The algorithm processes the file in chunks.
• Mix through rounds — Each block is transformed many times (bit operations, rotations, additions).
• Output a digest — The final result is the fingerprint stored in your proof record.

Good hashing algorithms are designed so it’s infeasible to: create two different files with the same fingerprint (collisions), or reconstruct a file from its fingerprint (preimage).

Why the timestamp matters

A fingerprint answers: “Do these two files match?” A timestamp anchored in an immutable registry adds: “And we can show when this fingerprint existed.” That matters in handoff, reviews, and disputes.

What gets anchored (and what does not)

• Anchored: fingerprint (hash), timestamp (plus blockchain reference), and minimal verification metadata.
• Not required: storing file content. Hash-only proof is enough to verify integrity later.

Tip: keep sensitive details out of public metadata. Share the verification link/QR instead of the file.

Verification: what the result means

• Match — the file is identical to the recorded original.
• Mismatch — the file changed (even a tiny edit, re-export, or metadata difference can trigger this).

Quantum: what we can safely say

People ask if fingerprints are “quantum-ready.” Hash-based fingerprints generally age well: the best-known quantum speedups don’t instantly “break” strong hashes, they mainly reduce brute-force margins. The practical takeaway is simple: use modern, strong hashing and avoid legacy options.

We also keep the system algorithm-agnostic. If cryptographic guidance evolves (including post-quantum standards), the fingerprint algorithm can be upgraded without changing what a proof record means: fingerprint + immutable timestamp.

Cryptography options: we’re not locked in

Proof records can support most widely used cryptographic building blocks, depending on customer needs:

• Hash algorithms for fingerprints (multiple families and strengths).
• Digital signatures (optional) to bind proofs to an identity or org workflow.
• Key management (optional) for enterprise automation and compliance.

Defaults should be well-vetted, widely implemented, and strong enough for long-term evidence.

What a proof record proves (and what it doesn’t)

• Proves: a file fingerprint existed at/around a recorded time, and a later file matches if the fingerprint matches.
• Does not automatically prove: legal authorship or ownership by itself.