Signing a page is easy. Verifying it is easier.
Most of the web asks you to trust a URL. A cryptographic signature gives you something stronger to rely on: a mathematical statement that this exact content was published by that specific identity. This page walks through the whole loop — signing, publishing, verifying — without magic.
Signing, step by step
-
Compute a fingerprint of the page
The file is hashed with SHA-256. Any change, however small — a single letter, a trailing space — produces a completely different hash.
-
Sign the fingerprint with a private key
The hash is signed with an Ed25519 key the publisher controls. For long-term resilience, a second signature is produced with the post-quantum algorithm ML-DSA-44 from NIST's 2024 suite.
-
Write a
.vrfysidecar next to the pageThe hash, signatures, timestamp, and a pointer to the signer's public identity go into a small JSON file named
<filename>.vrfy. The sidecar is deployed alongside the page. -
Publish the public key at a DID document
The signer's public key lives at a known URL like
jacqueslatour.ca/.well-known/did.json. This is a public decentralized identifier (did:web) — no ledger, no blockchain, no third-party account.
Verifying, step by step
A verifier — a browser extension, a command-line tool, or the widget on this site — can reach a yes-or-no answer without any privileged access:
-
Fetch the page and its
.vrfysidecarBoth are public. The verifier only needs HTTPS.
-
Re-compute the hash, compare to the manifest
If one byte of the page has changed since signing, the hashes won't match. The check fails before any cryptography is involved.
-
Resolve the signer's DID over DNSSEC-protected DNS
The verifier fetches
/.well-known/did.jsonfor the claimed domain, anchored to the domain's TLS certificate and DNS records. This is where the signer's public key comes from — not from a central registry. -
Check the signature against the public key
If the signature is mathematically valid for the manifest and the key is authorized by the DID document for signing assertions, verification passes.
Levels of assurance
Not every verification is created equal. The verifier returns a single cryptographic yes-or-no and an assurance level summarising how many independent anchors support the signer's identity.
- Maximum — cryptography + DNS anchors + trust-registry membership + post-quantum signature.
- High — cryptography + DNS URI and TLSA records confirm the signer controls the domain.
- Medium — signature is valid, but one identity anchor is missing or the DID is very new.
- Low — signature is valid but multiple soft signals are weak; treat with caution.
Each level maps to a concrete, auditable set of checks — not a vendor opinion. The full check list is visible on every verify result produced by the widget on this site.
What this does not require
- A blockchain or distributed ledger.
- A user account with a third-party platform.
- A central certificate authority beyond the standard Web PKI already used for HTTPS.
- Any special browser capability — a plain HTTP client plus DNS is enough to verify.