BitSeal's guarantees come from published cryptography, not from our word. Every seal is verifiable against a public key. Every primitive is standard. The threat model and key governance below describe what we can and cannot attest to.
Every seal is signed over the 40-byte payload root || LE_f64(timestamp) with Ed25519. High performance, standard curve, constant-time verification, no parameter choices to get wrong.
BLAKE3 drives the 64 KiB Merkle leaves and tree. A whole-file SHA3-512 is recorded alongside as a second, independent digest for long-term archival integrity.
Every manifest is signed before it is written to the ledger. Any alteration, accidental or malicious, invalidates the signature and is detectable by anyone holding the public key.
Files are chunked and hashed in your browser. The bytes never leave your device. The Authority only ever sees the manifest, which is the fingerprint plus metadata.
An attacker with our servers cannot retroactively forge past seals, every historical signature remains verifiable against the published public key. Live signing access, however, would let an attacker sign arbitrary new manifests. The Authority private key is stored in an isolated secrets environment with restricted access, rotated under the published key ceremony and rotation policy, and scheduled for migration to a hardware-backed KMS.
Client-side hashing means the file never crosses the wire. An attacker in the middle sees the manifest (root hash plus metadata), never the bytes. The signature is computed on payloads the client already possesses and can re-verify locally.
A second-preimage attack against BLAKE3 is not considered feasible with current or foreseeable compute. SHA3-512 is recorded in parallel as a structurally independent backstop. Both are standard, widely audited constructions.
The server re-derives the root from the supplied leaves before signing, so a client cannot pin a signature to a root that does not match its own leaves. Verifiers re-fold the stored leaves and compare, so tampering with the leaves relative to the signed root is detected on every verify.
The Authority key is the single root of trust for every BitSeal signature. Its generation, storage, and rotation are governed by two public documents.
How the current Authority key was generated, where it is stored, what we can and cannot attest to, and how to independently verify the published fingerprint.
Scheduled rotation cadence, emergency triggers that force rotation within 72 hours, and how retired keys remain valid for verifying past seals.
Think you have found a way to forge a seal, bypass verification, compromise the Authority key, or otherwise undermine BitSeal? Tell us before you tell anyone else.
[bitseal-security].Machine-readable version at /.well-known/security.txt per RFC 9116. BitSeal is a self-funded side project; we do not run a paid bug bounty. Reports are still very welcome.
Researchers who have reported valid vulnerabilities under the disclosure policy above. None yet. If that changes, your name will live here.