What Inverba proves — and what it doesn't.
Cryptographic tools are routinely oversold. This page states our guarantees precisely, names the assumptions they rest on, and lists the claims we deliberately do not make. If you find a gap between this document and our marketing, that's a bug — report it like one.
A valid record proves
The holder of the signing key asserted that this exact content (by SHA-256 hash) was received from this URL, at this time, under the recorded fetch context.
The record has not been altered since signing. Any modification to content hash, context, or timestamp invalidates the signature.
Once the planned transparency log ships: a record anchored in it existed no later than the Merkle root that includes it — a signer cannot backdate records after the fact. Until then, timestamps rest on P1 alone.
A valid record does not prove
That every visitor saw this content. A record captures one fetch from one vantage. Sites can and do serve different content to different visitors — that's precisely why Inverba has multi-vantage comparison, and why divergence findings carry confidence levels rather than verdicts.
That the signer was honest. A compromised or malicious fetcher can sign fabricated content. Signatures bind claims to keys; they do not make the claimant truthful. Corroboration across independent fetchers raises the bar — it does not eliminate it.
That the origin server wasn't compromised or fronted. Inverba records what the network returned for a URL. If DNS, a CDN, or the server itself was manipulated, the record faithfully proves you received the manipulated content — nothing more.
Legal authority to collect or use the content. Provenance is not permission. Inverba documents what you collected; whether you may collect it is a question for your counsel, not our cryptography.
Replay defense (agent handoffs)
A record is valid forever, which is the point — and also a hazard when one agent passes another an old observation as if it were fresh. A verifier can opt in to a seen-cache: re-presenting an already-accepted record returns a REPLAYED verdict instead of a second TRUSTED.
Per-verifier scope. The cache is local to one verifier. A record rejected as replayed by yours is unknown to anyone else's — this stops repetition, not distribution.
Bounded by cache lifetime. Protection lasts exactly as long as you configure the cache to remember. Past that window, a replayed record is simply a new one.
REPLAYED is advisory, not an accusation. A replayed record is still a true record of what was fetched. The verdict tells you this observation isn't new; whether that matters is your call.
Cross-verifier challenge-binding planned — binding a record to a verifier-issued nonce would close R1, but it's designed for the hosted enforcement layer and is not built.
Assumptions the guarantees rest on
- A1Ed25519 and SHA-256 remain computationally secure.
- A2Your signing key is not exfiltrated. Key custody is your responsibility; we support HSMs and rotation, but cannot verify custody.
- A3For the planned registry: its operator (us, or you if self-hosted) does not collude with a signer to fork the log — to be mitigated by public root publication and independent watchtowers, not eliminated. The log is not yet running.
- A4System clocks on fetchers are approximately correct; the planned registry anchoring would bound timestamps from above but not below.
Responsible disclosure
Report vulnerabilities to security@inverba.dev (PGP key at /.well-known/security.txt). We acknowledge within 48 hours, and we credit reporters unless asked not to. The core is Apache-2.0 — the fastest way to check our claims is to read the code.