tessera

Overview

tessera is a protocol for messaging that authenticates the sender while hiding who is talking to whom. Those two properties normally trade against each other: a signature proves identity and is a stable identifier, and a stable identifier is exactly what metadata privacy is trying to withhold. Most systems therefore pick one, and the gap between them is where this project sits.

Authentication uses a Schnorr proof of knowledge made non-interactive by the Fiat-Shamir transform, evaluated not against a global public key but against a per-recipient blinded pseudonym. The blinding scalar is derived from a seed shared with that one recipient during enrolment, so each contact sees a different pseudonym for the same sender, and two contacts comparing records cannot establish that they correspond with the same person. Message payloads are encrypted separately with AES-GCM.

Traffic analysis is handled with cover traffic whose guarantee is stated as a number rather than as an assurance. Decoys are drawn from a distribution calibrated to bound by (epsilon, delta) how much the per-bucket counts an observer can see shift their belief about whether a particular real message was sent. Making the bound explicit means it is tunable, and means it does not quietly degrade when traffic is light — which is when naive cover-traffic schemes leak most.

Delivery uses a bucketed broadcast network with Bloom filters for efficient retrieval and gossip between relays, rather than a mix network. A mixnet hides the path through successive hops and pays in latency and in the assumption that one hop is honest; bucketed broadcast hides the pairing by giving observers only counts and pays in bandwidth. Neither dominates, and knowing how each fails is more useful than a ranking.

Enrolment is pairwise and local. There is no directory, no key transparency log and no central authority, which means there is no operator who could be compelled to produce the mapping between identities and pseudonyms.

The scope boundary is the endpoint. Every guarantee assumes the device and its key material are intact; an adversary who owns the endpoint reads plaintext and can produce valid proofs, and no protocol property survives that. The construction is also for one-to-one messaging, and group semantics raise linkability questions it does not answer. The project is experimental: the source is public and MIT-licensed, and the protocol has not been independently audited.

For anyone assessing this, the useful first question is which adversary you are actually worried about. If it is somebody reading message contents, established end-to-end encryption already solves that and this adds nothing. If it is somebody reconstructing who corresponds with whom from delivery records — a service operator, a subpoena, an acquirer, a breach — then content encryption does not help and the metadata layer is the whole point. Answering that question first avoids evaluating the protocol against a threat model it was never built for.