Skip to content

Cryptographic assumptions

This page describes assumptions that a verifier or operator must make; it is not an audit of the implementation. Witness is pre-1.0 and unaudited.

Inputs and signatures

Witness timestamps a client-supplied SHA-256 hash. A client must calculate or otherwise obtain the intended hash and verify the returned signed attestation against the correct network verification configuration. A signature proves that a configured witness key signed the canonical attestation data; it does not prove authorship, ownership, or the contents that produced the hash. For a BLS aggregate, the configured key membership and witness/key bindings must also come from a trusted registration process with proof-of-possession (PoP); the current verifier does not perform those PoP checks itself.

The network selects Ed25519 multi-signatures or BLS12-381 aggregation. A result is accepted at the configured witness threshold after the gateway verifies the individual or aggregate signatures. In BLS mode, the threshold is applied to the distinct signer IDs supplied with the aggregate. Without trusted key registration and PoP, that list is not sufficient evidence that the corresponding number of distinct witnesses participated. BLS aggregation does not change the trust assumption that enough configured witness keys can collude.

Trust assumptions

  • Key generation uses a secure random source.
  • Private keys remain protected on witness hosts.
  • Public keys and the network ID/threshold in the verifier's configuration are correct and independently reviewed when needed.
  • BLS public keys were admitted through trusted membership registration with a verified proof-of-possession and an authenticated witness/key binding.
  • Clients verify signatures, witness identities, threshold, and any requested proof bundle rather than trusting a gateway status alone.
  • Witness and gateway clocks are sufficiently synchronized for the configured timestamp/skew policy.
  • The cryptographic libraries, canonical serialization, Merkle/log proof code, and release artifacts are correct. This project has not had an external cryptographic or protocol audit.

Logs and federation

Merkle inclusion and RFC 9162 consistency proofs provide evidence within the signed-tree-head model. They do not make operator logs universally tamper-proof or establish global ordering across networks. Federation and external anchors add independent durability signals, not Byzantine consensus or finality.

No cryptographic assumption removes the need for TLS at the edge, bearer authentication between services, secure handling of key material, or review of outbound destinations. The hardened SSRF-filtered client covers witness, federation, Freebird, and Internet Archive paths; Trillian/DNS use unrestricted reqwest, and Ethereum has URL preflight validation only.