Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Paper cross-reference

audience: contributors

Pointer table from the prototype’s source modules to the ZIPNet paper (eprint 2024/1227). Section / algorithm / figure numbers are from the camera-ready version. Crate paths are workspace-relative.

Paper itemPrototype location
§2.1 “Chaum’s DC net” (background)zipnet-proto::xor (crates/zipnet-proto/src/xor.rs)
§2.2 “ZIPNet overview” (Figure 1b)crates/zipnet-node/src/lib.rs diagram + Architecture
§3 “Falsifiable TEE assumption”zipnet-proto::crypto::falsification_tag (crates/zipnet-proto/src/crypto.rs)
§3 “Setup” (PKI, attestation, sealed key DB)zipnet-proto::keys + zipnet-node::tickets::BundleValidator (crates/zipnet-node/src/tickets.rs)
§3 “Sealed data”v2 sealed storage in TEE; not implemented in v1
§3.1 “Rate limiting tags”v2 item; not implemented
§3.2 “Scheduling” (footprint)v2 item; not implemented (see roadmap)
§3.3 “Adversary and network model”Threat model
§3.3 “Security argument”Threat model — anonymity sketch
Algorithm 1 (client seal)zipnet-core::client::seal (crates/zipnet-core/src/client.rs)
Algorithm 2 (aggregator fold)zipnet-core::aggregator::RoundFold (crates/zipnet-core/src/aggregator.rs)
Algorithm 3 (server partial + finalize)zipnet-core::server::partial_unblind + zipnet-core::server::finalize (crates/zipnet-core/src/server.rs)
Appendix A (anonymous broadcast definition)inherited — the prototype does not reprove it

Crate responsibilities

The workspace splits the paper’s constructions along a purity boundary (see Crate map):

CratePaper contentI/O?
zipnet-protoWire types, keys, XOR, falsification tag primitiveNo
zipnet-coreAlgorithms 1 / 2 / 3 as pure functions over zipnet-proto typesNo
zipnet-nodeThe mosaik integration — CommitteeMachine, role event loops, TicketValidatorYes
zipnet-server / zipnet-aggregator / zipnet-clientThin CLI wrappers around zipnet-node::roles::{server, aggregator, client}Yes
zipnetSDK facade (Zipnet::<D>::{submit,receipts,read}, Config, UNIVERSE); wraps zipnet-node for external consumersYes

zipnet-proto and zipnet-core do not import mosaik or tokio; if a paper construction reaches for either, it is in the wrong crate.

Notation

The paper uses capital N (total users), N_S (servers), |m| (slot bytes), B (broadcast vector bytes). The prototype uses lowercase n / num_slots / slot_bytes / broadcast_bytes in code and generally follows the paper’s naming in comments.

Deliberate deviations from the paper

  • No schedule hash in v1. The paper mixes publishedSchedule into the KDF salt. The prototype passes a constant NO_SCHEDULE = [0u8; 32] in v1 and will replace it with the real schedule hash when footprint scheduling lands. Binding the schedule into the KDF is already plumbed (crypto::kdf_salt takes it as an argument), so the upgrade is a caller-site change.
  • Tag is keyed-blake3, not HMAC. The paper writes “ROMHash” informally; the prototype picks keyed-blake3 with a fixed domain-separating label for performance. Both are PRFs under standard assumptions; no security difference relative to the paper’s ROM-based argument.
  • No traitor tracing protocol. The paper’s §3 suggests that any malformed message flips hash bits and is detected with overwhelming probability. v1 only checks tags on observation; an adversarial client writing to an unused slot is visible via tag mismatch but not attributed. This matches the paper’s “falsifiable trust assumption” but does not implement the §3.1 rate-limiting PRF tags.
  • Anonymous broadcast channel for scheduling. The paper runs a second DC net for reservations (§3.2). v1 runs only the message channel.
  • Deployment fingerprinting replaces paper-implicit single- deployment identity. The paper treats a ZIPNet committee as a single global entity. The prototype runs many deployments side by side on a shared mosaik universe, each with its own content + intent addressed fingerprint (see Designing coexisting systems on mosaik). No paper construction is changed by this; every derivation folds Zipnet::<D>::deployment_id(&Config) in where the paper has an implicit single “deployment” constant.