The format, published and pinned.
A VerifyBundle record can be checked without connecting to this website. The verification materials are published here: the offline verifier, the specification, and the conformance vectors. Each is pinned by a SHA-256 so you can confirm the file you hold is the exact one published, before you trust it to verify anything.
Recompute the artifact hash and compare it with a reference you retained independently. A file and hash downloaded together from this site provide a consistency check, not independent authentication. No independent mirror exists yet, and the source repository is private, so this site is the only place these files and their hashes are published today. Verification is in-browser math over the bundle bytes: Ed25519 (RFC 8032) and SHA-256 (FIPS 180-4) for v1 records, plus ML-DSA-65 (FIPS 204) for the v2 post-quantum hybrid.
Verification artifacts and published hashes
Recompute each SHA-256 after downloading. A match identifies the bytes listed here; it does not establish their correctness or independently authenticate this site. A mismatch requires investigation.
| Artifact | Published SHA-256 · size |
|---|---|
| verifier.html The offline verifier: one self-contained HTML file. Open it directly, with the network off, and verify any record. No server, no account, no network. September 30 revision: hosted and offline verifiers use fflate 0.8.3, refuse ZIP64 and ambiguous JSON, and run checks in a cancellable worker. The previous download is retained in the archive for historical byte comparison. | 6452907bb7c5062a0193e3f1528d427c614231a313b879e285d7d901c5d76987 84,013 bytes |
| VERIFYBUNDLE_SPEC.md The normative specification: the bundle and seal format, the canonicalization, the Merkle and checkpoint construction, and the verification rules. Enough to re-implement the verifier from scratch. | bd55d29e66f9839a7dd092eb2f175487d073a10cf6dd09b49702c5c2d1980962 51,933 bytes |
| verifybundle-conformance-vectors.zip The golden conformance vectors (v1 Ed25519, the v2 hybrid ML-DSA-65 + Ed25519, and the v2 time-bound vector pinning the content-bound time attestation), so an independent re-implementation can prove it agrees on frozen bytes. | 4f3c8f2968a5a23124ba87b27e2c06abe60330ce5fff1080775a5bddd2d2bb49 59,554 bytes |
Previous verifier, retained bytes. Its ZIP64 and repeated-field limitations remain; use the current verifier for new checks. Its SHA-256 is recorded in the trust-root history.
September 30 issuer-key policy: a supplied malformed or different expected key fails verification. Only an omitted key selects an integrity-only check. This intentionally tightens the legacy R4.1.5 malformed-input behavior without changing signed record bytes. The historical specification and vectors retain their original bytes and terms.
Every earlier root, with the date it was pinned, is on the trust-root history.
Verify a record yourself
Check what we serve. The hash confirms your copy is the one this page publishes; it cannot protect you from this site itself. For that, re-implement the verifier from the spec and vectors.
- Download verifier.html from the table above.
- Compute its SHA-256 and confirm it equals the trust root 6452907b…. If it differs, do not trust it.sha256sum verifier.htmlshasum -a 256 verifier.htmlcertutil -hashfile verifier.html SHA256
- Open the file directly (double-click, so it loads over file://), with the network disconnected.
- Drop in a .vbundle (or paste its bundle.json). A record changed after sealing shows FAILED under its own key. Content re-sealed under a new key shows VERIFIED, so compare the record's public key or hash with one you received independently. No server, no account, and no network involved.
- For a file record, the verifier checks the record, not your copy of the file: hash the file yourself (sha256sum yourfile) and compare it with subject.bytes_hash as the verifier's readout shows it. Both current verifiers refuse repeated JSON field names, invalid UTF-8 and excessive nesting. Read verified values from the result, and distinguish them from unsigned metadata.
The verifier carries a Content-Security-Policy of connect-src 'none', so the browser blocks any network call at runtime, not merely in the source. It is one self-contained file: everything it runs is in the bytes you just hash-checked, and the published specification below is enough to re-implement it from scratch.
Re-implement the verifier from scratch
You do not have to use our verifier at all. Follow the specification and check your implementation against the conformance vectors, which pin the expected bytes for both signature profiles.
The specification and conformance vectors remain available to download for inspection. No separate reuse or redistribution license has been issued for those materials, and the source repository remains private. Licenses for third-party components bundled in verifier.html are listed in the third-party notices. Those notices do not grant rights to the VerifyBundle source, specification, or conformance vectors.
What the signed receipt contains
- A SHA-256 of your file's bytes and a hash of its metadata, or one manifest hash for several files.
- The public fields you entered, including the title and the filename, in clear.
- Any private fields, encrypted under your password.
- The seal time from your device clock and, when sealed online, a time attestation: an Ed25519 signature from VerifyBundle's own time service, not an accredited timestamping authority, covering the sealed content's hash only. A record without one is labelled not independently time-attested.
- The signing public key and the signature.
A file's bytes are not in the record; a sealed note's text is. The .vbundle file also carries a README.txt, which is not signed. A hash does not hide short or guessable content: anyone can hash candidate values and compare, so put values like names, dates or yes/no answers in a private field with a strong password. The exact construction is in the specification.
Verification does not depend on this site staying up. A copy of the verifier you already hold keeps checking records offline, on your own device, even if this site is gone; and the spec is published, so the verifier can be re-implemented from it and proven against the conformance vectors. Wherever you obtain a copy of an artifact, the trust root above is what you check it against: it is always the current one.
ML-DSA-65 · FIPS 204 · Ed25519 · RFC 8032 · SHA-256 · FIPS 180-4