Skip to main content
AlgoVoi Reseal quantum-seals evidence you already hold. Every post-quantum product on the market protects tomorrow’s data; Reseal rescues yesterday’s. A document signed with RSA or ECDSA stays provable only while those algorithms stay unforgeable. Records on decade-long retention clocks (contracts, clinical records, deeds, qualified e-signatures) outlive that window: once a quantum adversary can forge the classical signature, the original can no longer be told apart from a tamper. The rescue is only possible now, while the classical signature still verifies. Reseal verifies it today and binds that verification into a Falcon-1024 + ML-DSA (65 or 87), RFC-3161 timestamped, offline-verifiable attestation.

​
Two parts: an open verifier and a licensed sealer

Verification is open on purpose: you should not have to trust the sealer. Anyone can verify what a seal proves, from the bytes alone, with no AlgoVoi service in the trust path.

​
Verify or inspect (free, open)

Exit codes: 0 verified and anchored, 1 failed, 2 malformed, 3 cryptographically intact but the signing key is self-asserted (pin the sealer’s published kid with --expect-kid to anchor authenticity).

​
Seal (licensed)

After purchase on the Suite Store you receive an index token and a licence key. Install the sealer from the token-gated AlgoVoi index (its public dependencies come from PyPI):
The index token is a secret. Prefer configuring it out of the command line so it does not land in shell history or CI logs, for example with pip config or a PIP_EXTRA_INDEX_URL / netrc entry, rather than pasting it inline.
Then set your licence and seal:
Sealing requires a valid licence; inspection and verification never do.

​
Two signing profiles

Both are first-class; the verifier accepts either and neither can be downgraded (the algorithm set is bound inside the signed payload).

​
What it understands

  • PDF embedded signatures (PAdES / PKCS#7): every /ByteRange CMS signature, with a shadow-attack partial-coverage check and a SHA-1 weak-digest flag.
  • Detached CMS (.p7s) over any file.
  • Optional offline trust-path and CRL revocation validation (--trust-roots, --crl), air-gap capable, no OCSP fetch.
  • Optional RFC-3161 time anchoring (--tsa-roots); unanchored timestamps are labelled, never presented as authoritative.

​
Trust model, stated honestly

An attestation carries its signing public key, so verification proves it is internally consistent and unaltered, not who sealed it. Anchor authenticity by pinning the sealer’s published kid (--expect-kid, a full 256-bit digest). The dual signature is bound inside the signed payload, so ML-DSA cannot be stripped to fall back to Falcon-only. Signatures cross-verify against liboqs (Open Quantum Safe) in both directions. Reseal produces cryptographic evidence artifacts. It is not a guarantee of legal admissibility or regulatory compliance; treat each attestation as a per-record, independently verifiable proof.

​
Standards

RFC 8785 (JCS), RFC 3161 (timestamping), RFC 5652 (CMS), RFC 5280 (X.509), FIPS 204 (ML-DSA), FIPS 206 draft (FN-DSA / Falcon).

​
Frequently asked questions

​
What is AlgoVoi Reseal?

AlgoVoi Reseal quantum-seals evidence you already hold. It verifies a document’s existing classical signature (RSA or ECDSA) today and binds that verification into a Falcon-1024 plus ML-DSA (65 or 87), RFC-3161 timestamped, offline-verifiable attestation. A free open verifier inspects exposure and checks seals; a licensed sealer mints them.

​
How is Reseal different from other post-quantum products?

Every post-quantum product on the market protects tomorrow’s data. Reseal rescues yesterday’s. Documents on decade-long retention clocks (contracts, clinical records, deeds, qualified e-signatures) were signed with RSA or ECDSA and stay provable only while those algorithms stay unforgeable. Reseal re-anchors them while the classical signature still verifies, which is the only time the rescue is possible.

​
Is the verifier really free and open?

Yes. algovoi-reseal-verify is published on PyPI under Apache-2.0. It inspects what is signed on a document, whether it verifies today and how exposed it is, and it verifies any reseal attestation offline. Verification is open on purpose: you should not have to trust the sealer to check what a seal proves.

​
Does verifying a seal depend on AlgoVoi?

No. An attestation carries its own signing public key and recomputes from its own bytes under RFC 8785 (JCS) and SHA-256, so an auditor verifies it offline with no AlgoVoi service, account, or network call in the trust path. Pinning the sealer’s published key id with --expect-kid anchors authenticity, and the dual signature is bound inside the signed payload so ML-DSA cannot be stripped.

​
Which signatures and standards does Reseal use?

Dual post-quantum signatures: Falcon-1024 with ML-DSA-65 (Compact profile, L5 plus L3) or ML-DSA-87 (Matched profile, both at NIST L5), plus one RFC-3161 timestamp per batch. It reads PDF PAdES/PKCS#7 and detached CMS (.p7s) signatures and follows RFC 8785, RFC 3161, RFC 5652, RFC 5280, and FIPS 204.

​
How much does Reseal cost?

The sealing engine is a licensed product from 99 USD perpetual or 39 USD per year, bought self-serve from the suite store. Inspecting exposure and verifying seals is always free with the open av-reseal-verify tool and never needs a licence.

​
See also

  • Reseal overview: the product page, with the exposure problem, the two signing profiles, and pricing.
  • Evidence Auditor: batch-verify a whole archive of signed documents and produce a signed, tamper-evident audit report.
  • Compliance Suite: store write-once, retain, place legal holds, run a console, and seal at scale.
  • Post-quantum evidence longevity: why Falcon-1024 and ML-DSA keep evidence verifiable for decades.