Public key verification explained: what checking a signature actually tells you
Public key verification is the process of checking a digital signature against the signer's published public key, so anyone holding the signed data, the signature and that key can confirm the data has not changed since it was signed and that it was signed by the matching private key.
What does public key verification mean?
It means the check does not depend on the party asking you to believe something. Two keys are generated together as a pair. One stays private and produces signatures. The other is published and checks them, and it cannot produce a signature of its own.
For a compliance or claims reader, the consequence is the interesting part. A supplier can hand over a file, a signature and a key, and your own technical team, an outsourced forensics firm, or the other side's expert can run the check on their own equipment. Nobody has to log into a dashboard and trust a green tick.
How does public key verification work?
- Hash the data. The signer runs the file or the manifest through a hash function such as SHA-256, producing a short fixed-length fingerprint.
- Sign the fingerprint. The private key operates on that fingerprint to produce a signature specific to that exact content and that exact key.
- Publish the public key, usually as a certificate, so the key arrives wrapped in a statement about who holds it, when it was issued and when it expires.
- Verify. The recipient recomputes the hash from the data in front of them, runs the signature check with the public key, and gets pass or fail. One changed byte fails it.
None of this is exotic. It is the same machinery behind the padlock in a browser and behind signed software updates, pointed at evidence instead of network traffic.
The part most descriptions skip: how you trust the key
Verification is only as strong as your confidence that the public key belongs to whoever you think it belongs to. A signature validates perfectly against an impostor's key, if the impostor also supplied the key. That problem, not the mathematics, is what public key infrastructure (PKI) exists to manage.
So the questions worth putting to a provider are about key handling:
- Where is the public key published, and can a third party obtain it without going through the provider's support desk?
- Self-signed or certified? A certificate from a recognised certificate authority carries an outside statement about the key holder. A self-signed key carries only its own.
- What happens on rotation. Keys get replaced. Signatures made years ago must stay verifiable against the key that made them.
- What happens on revocation, if a private key is ever compromised, and how signatures made before the compromise are treated afterwards.
- Which algorithm, which key length, and is the signature format a documented standard rather than a proprietary blob only that vendor can read?
Public key verification example: the expert who does not trust your system
A property damage claim goes to dispute two years after settlement. The insurer produces the original submission, its signed manifest and the published key. The policyholder's expert never opens the insurer's platform. He recomputes the SHA-256 hash of each file, runs the signature check, and confirms the package matches what was signed on receipt.
The argument then moves on to the surveyor's reading of the damage, which is where it belonged. One whole line of attack, "you could have edited this", closes without a hearing.
How it differs from a checksum and from a platform status flag
A bare checksum proves a file has not changed, provided you already hold a trustworthy copy of the original hash. It says nothing about where that hash came from. Anyone can recompute a hash for an altered file and publish that one instead.
A signature supplies the missing half. The fingerprint is bound to a key holder and cannot be quietly reissued. A "verified" badge inside a vendor's interface supplies nothing at all in a dispute, because it is the vendor's opinion of the vendor's own record.
What public key verification does not prove
- Not the truth of the content. A signed, verified recording can still show a staged scene or damage that predates the policy.
- Not the person. The check ties a signature to a key. Who controlled that key at that moment is a separate evidential question, which is why non-repudiation is a weaker claim than the word suggests.
- Not when the event happened. Where the signature covers a receipt timestamp, it proves when the receiving system took delivery. That is the whole of it.
- Not admissibility. Article 25(1) of the EU's eIDAS Regulation (910/2014) provides that an electronic signature "shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form". Not denied on that ground is not the same as accepted.
When does public key verification matter?
Whenever the record may one day be read by someone with no reason to trust you: a regulator, an ombudsman, an auditor, a court-appointed assessor, or opposing counsel. On a settled file it is invisible. On a contested one it decides whether the evidence gets argued about or accepted.
It sits on top of the wider evidence integrity stack and underneath the sealed submission. The seal is the thing being signed, the public key is how a stranger checks it, and the chain of custody is the surrounding account of who held what, and when.
Venta Capture, a product of VentaVid, signs each submission on receipt and publishes the key, so the seal can be checked outside the platform, alongside SHA-256 fingerprints on every file received and a recorded session timeline.